The basic idea behind the integrated services architecture is to give differ-ent treatmdiffer-ent in the routers to packets belonging to differdiffer-ent flows. For
instance, datagrams from a real-time flow can be tapped for forwarding ahead of datagrams from a low-priority flow. Routers handling a particular flow will need additional information in order to forward its datagrams properly: namely information on how to distinguish the datagrams in one flow from datagrams belonging to other flows and what class of treatment each datagram is due.
A router might prioritize all datagrams with a certain destination IP address and a certain UDP destination port number, while continuing best efforts for datagrams with a different destination. In the latter case, a router handles several flows and therefore has to implement different packet filters in order to classify the datagrams it receives. The default is best effort, which is what packets that do not belong to any flow known by the router receive.
Services Available The integrated services architecture currently pro-vides two services: controlled-load and guaranteed services. They represent two levels of better-than-best-effort services (Figure 3-17).
Packets benefiting from controlled-load services are given priority over effort traffic. Therefore, even if the network is congested with best-effort traffic, the controlled-load service delivers the datagrams as if the network were under moderate load. This service does not guarantee any particular bandwidth or delay for a certain flow; it simply ensures that packets get superior treatment.
Guaranteed service, as the name suggest, provides a certain bandwidth and a delay bound for a particular flow. Therefore, the jitter observed for guaranteed traffic is small to negligible.
Incoming interface
Best-effort service Cotnrolled–Load service
IP packet IP packet Packet
filter
Because a router cannot grant high-priority treatment to an unlimited amount of traffic, routers need the capability for admission control and resource reservation.
Upon receiving a request for handling a new flow, a router checks whether it has enough available resources to accept it without impacting other flows in progress. If the QoS requested for the flow can be granted, it reserves resources for the newcomer.
State Information Stored in the Network We’ve just seen that routers must store information about flows in order to differentiate data-grams properly. This implies that the network stores state information. Pre-viously, we argued that doing so flies in the face of the IP paradigm, pushing the intelligence to the end systems and storing as little state as possible in the network. The trade-off for less information is more robust systems that tolerate network failures better. Acknowledging the value of the paradigm and the need to make exceptions to it on well-defined occasions, reserva-tion merging and soft states help minimize the problems that excepreserva-tions can cause.
Reservation Merging Figures 3-18, 3-19, and 3-20 show how reservation merging is performed in a multicast group. We saw in Figure 3-13 how the shared distribution tree was calculated for that topology. In Figure 3-18, we now assume that 131.160.1.112 is the sender and the other hosts, 153.88.251.19 and 138.85.27.10, are the receivers.
Receiver 138.85.27.10 requests a certain QoS for its incoming flow. The routers in the path store the necessary state in their packet filters and the QoS requested is honored (Figure 3-19).
Now receiver 153.88.251.19 also requests QoS for the flow it is receiving.
However, the second host won’t need to request QoS for the entire path from the sender because a QoS reservation is already present in part of the path for the same flow. Therefore, when 153.88.251.19 requests QoS, state infor-mation stored in the routers in the path that was already provisioning QoS for the first host does not increase. New state information is limited to those routers in the path from 153.88.251.19 to the main distribution tree (Figure 3-20).
131.160.1.112
138.85.27.10
QoS requested by 138.85.27.10 Best-effort service
153.88.251.19
ROUTER
ROUTER
ROUTER ROUTER
ROUTER ROUTER
ROUTER
Figure 3-19 138.85.27.10 requests QoS for the flow.
131.160.1.112
138.85.27.10
153.88.251.19
ROUTER
ROUTER
ROUTER ROUTER
ROUTER ROUTER
ROUTER
Figure 3-18 Distribution tree with 131.160.1.112 acting as a sender.
Soft States Implementing soft states increases the system robustness. Soft states store state information temporarily, after which the router removes all the state it was storing. Under this system, if the state information is not refreshed periodically, it will expire and enable the release of all the resources reserved in the router. Soft states are typically refreshed by send-ing a message to the router with the proper information, whereas hard states are stored permanently and require a release-of-state command to relinquish resources.
ReSerVation Protocol (RSVP) ReSerVation Protocol (RSVP) [RFC 2205] is the protocol used for resource reservation in the network. RSVP installs the necessary state in the routers and refreshes it periodically.
Reservations for a particular flow are initiated by its receiver; the messages that store state from the receiver to the sender are called RESV messages.
However, IP datagrams from the receiver to the sender do not typically follow the same path as datagrams in the opposite direction. Thus, an RSVP message (PATH message) from the sender to the receiver of the flow has to
131.160.1.112
138.85.27.10
QoS requested by 138.85.27.10 QoS requested by 153.88.251.19
153.88.251.19
ROUTER
ROUTER
ROUTER ROUTER
ROUTER
ROUTER
ROUTER
Figure 3-20 153.88.251.19 also requests QoS.
be sent prior to resource reservation in order to scout out which path the datagrams belonging to the flow will follow. PATH messages contain the path that RESV messages must traverse backwards towards the sender installing state in the router. Figure 3-21 shows an RSVP message flow.
The use of soft states also prevents the network from retaining unneces-sary state information when routes change. If the route towards the flow destination changes as a consequence of the routing protocol operation, all of the datagrams will take a new route. Periodic PATH messages will also take the new route. Routers in the old route will not receive any more PATH messages, and therefore no RESV message will be received either. At that point, the state stored in those routers will time out and be deleted.