The basic idea behind the integrated services architecture is to give differ- ent treatment in the routers to packets belonging to different 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 best-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 Outgoing interface IP packet IP packet IP packet IP packet Guaranteed service Router IP packet IP packet IP packet IP packet Figure 3-17 Packet filter in a router.
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 exceptions 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.
Differentiated Services (DiffServ)
We have seen that RSVP and the integrated services architecture provide different treatment for different flows in the routers. Routers filter packets based on the information received in RSVP messages. For instance, as long as flows are defined by the destination address and destination port num- ber of the packets, routers have to examine the destination address and
Sender Router1 Router2 Receiver
Packets of the flow (1) PATH: Sender
Packets of the flow Packets of the flow
Packets of the flow Packets of the flow Packets of the flow
The information received in the PATH message is used to route the RESV message towards the sender (2) PATH: Sender Router 1 (5) RESV: Router 1 Sender (1) RESV: Sender (3) PATH: Sender Router 1 Router 2 (4) RESV: Router 2 Router 1 Sender Figure 3-21 RSVP message flow.
port number of every datagram and map it to state information. The differ- entiated services (DiffServ) architecture [RFC 2475] simplifies the task by defining several traffic classes with different priority levels. Packets are tagged at the edge of the network with the required priority level. Routers in the network take their cue from these tags; each tag is associated with a particular way of handling packets (referred to as Per-Hop Behavior[PHB]), and the router only has to read the tag and look up its PHB. Examples of standard PHBs include expeditedforwarding [RFC 2598] andassuredfor- warding [RFC 2597]. The former imitates the behavior of a circuit-switched network and the latter provides drop precedence.
DiffServ scales better than integrated services because it releases routers from the requirement to maintain per-flow state. Even with Diff- Serv, however, networks still need admission control mechanisms. Other- wise nothing would prevent end systems from tagging all traffic as high priority and swamping the network. RSVP can be used for admission con- trol, so expect to see RSVP and DiffServ used together for maximum scala- bility, as shown in Figure 3-22.
RSVP RSVP RSVP Differentiated services Figure 3-22 DiffServ and RSVP working together.