9.5. Quality of ServiceQuality of Service is sometimes meant to refer to all measures that are geared toward improving the performance of voice on the converged network: 802.1p, VLAN, DiffServ, RSVP, and so forth. But within the context of VoIP, QoS is also a way of saying "more elaborate than CoS." That is, QoS takes additional steps beyond those CoS solutions that 802.1p and DiffServ take. The two key QoS standards are RSVP and MPLS. 9.5.1. Intserv and RSVPIntserv (Integrated Services) is an IETF recommendation for provided dedicated bandwidth to individual flows, or media channels, on an IP network. The media channels are referred to by their sockets, just as they are in DiffServ. But, the difference is that all routers, whether at the edge or core of the network, play an active role in the policy decision process that results in dedicated bandwidth for each successful request. RSVP (Resource Reservation Protocol) is the recommended signaling protocol for Intserv. This standard is a good choice for routed networks with limited core bandwidth. The Resource Reservation Protocol adds a layer of preflight signaling to IP networks that is similar to ATM (asynchronous transfer mode) switched networks. The purpose of RSVP is to ensure that the network has enough bandwidth to support each call, before any data is passed through the media channel. This is a decidedly different approach than DiffServ, which deals merely with packet prioritization. And unlike DiffServ, RSVP adds decision-making points to the core network, increasing the processing overhead requirement on core routers. The increased overhead tends to discourage RSVP's use in bandwidth-glutted networks. But RSVP is the perfect solution for bandwidth allocation over slower links, because it guarantees availability for each RTP stream, rather than giving a "best effort." In this fashion, voice systems can tell routers, at the edge and the core, to reserve dedicated bandwidth for the duration of each call.
So RSVP is QoS, not CoS. It is an end-to-end solution that sets up a reservation across every hop that the call path crosses. Unlike DiffServ, RSVP runs after the call is set up. It uses the session ID of the RTP stream in order to identify a bandwidth reservation request. Each request forms a piece of a chain along the route between caller and receiver. This chain, or path , is put in place as soon as the RTP stream's session ID is determined during call signaling (H.245 or SDP). In the case of Figure 9-5, the call path follows the logical path through the network cloud, crossing four routers along the way. Once the path is established, a traffic reservation must occur. Here's how RSVP works with an H.323 VoIP network, using Figure 9-5 and H.323 to illustrate the context. Figure 9-5. An example of slow links between routers. RSVP is the preferred QoS technique for slow networks.
So the ADSPEC portion of the path message for a call in Figure 9-6 would have a cumulative link delay (latency) of 75 ms and a cumulative maximum jitter of 22 ms. Because of jitter buffers and queuing, these two figures are added together in order to determine the effective latency that will be experienced during the callnot accounting for overhead on local data links or for packetization delay. In this case, there will be 97 ms of latency. Figure 9-6. As the RSVP path message traverses the network, link delays (latency) and maximum jitter readings are recorded for each hopWhen the remote gateway router reads the ADSPEC data and makes the determination, it can do one of two things:
This decision can be driven by local programming or by policy established on a COPS/LDAP server. In order to establish the traffic contract, the remote gateway (D) begins by sending an RM to the next hop (C) on the route back to the caller's gateway router (A). This path will always be the exact reverse of the path established during the earlier PM step. Now, that path is used to negotiate a traffic contract with each router:
So the RSVP conversation has traversed the call path twice: once to establish the call path and once to backtrack the call path in order to send RMs. Now, the last stage of RSVP bandwidth allocation occurs as the call path is traversed a third and final time with RM responses:
If any rejection occurs, the session setup will fail, the RTP traffic will not pass, and the calling user should hear a busy tone. ( Should hear, because different VoIP endpoints may handle this situation differentlyeven going as far as playing a recorded message like, "Your call cannot be handled at this time.") 9.5.1.1 Controlled loads versus guaranteesRSVP defines three service levels in RFC 2211:
The decision of which level of service to enforce with RSVP is up to you, the administrator. It makes the most sense, if you're going to go to the effort of setting up RSVP, to use the Guaranteed class, as the other classes are comparable to DiffServand DiffServ is simpler to implement. That is, if you aren't going to use Guaranteed, you may do just as well to use DiffServ.
RSVP has the following general characteristics:
9.5.2. MPLSMultiprotocol label switching is the most advanced QoS measure available for enterprise VoIP networks. MPLS bears great similarity to ATM signaling but borrows heavily from RSVP. Unlike ATM, which incurs a 25% overhead on TCP/IP traffic (called the ATM " cell tax"), MPLS doesn't use its own framing format, just its own labeling format. This gives it the ability to work with Ethernet and other non-ATM switching technologies. MPLS's role is in carrier-grade networks or extremely large enterprise networks with tens of thousands of nodes. Carrier-grade networks can use a mixture of MPLS, DiffServ, and RSVP all carried on a legacy ATM topology even as they seek to migrate away from ATM. MPLS can be supported by just about any modern topology. The purpose of MPLS labels is to identify the paths and priorities associated with each packet. The paths correspond to the media channel of the VoIP call, while the priorities respond to the QoS level of service negotiated for those channels, just like RSVP. But like DiffServ, MPLS can use a dumb network core. If a packet is carrying a label, all a router has to do is send it along the labeled path, rather than making a redundant assessment of the packet's payload. With MPLS, specialized, narrow-function circuitry can handle gobs more traffic than a traditional, CPU-based router can.
MPLS inserts itself partially in layer 2 and partially in layer 3 on the OSI model. Its frame header sits between the IP header and the Ethernet header on an Ethernet network or between the label header and the payload on an ATM network. What's important to know is this: MPLS resides outside the reach of the network protocol, like 802.1p. But unlike 802.1p, MPLS also resides outside the reach of the data link's framing protocol (Ethernet framing, for example). This makes it invisible to the higher layers . Like ATM, MPLS performs both switching (at a very high speed) and bandwidth reservation, so its ability to maintain fixed-bandwidth media channels for VoIP is superior . MPLS is as much a network routing and switching standard as it is a QoS mechanism. But, unlike ATM, MPLS can work with many kinds of data link/transportEthernet, ATM, frame-relay, and so forth. If you're intent on using it, please read up on the subject at the MPLS and Frame Relay Forum's web site: http://www.mplsforum.org/tech/library.shtml. MPLS has the following general characteristics:
|