Section 9.5. Quality of Service

9.5. Quality of Service

Quality 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 RSVP

Intserv (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.

RSVP isn't needed in small setups. If you have a two-office VoIP network with 50 endpoints at each office, RSVP is overkill. Simplify your QoS approach by using 802.1p and, if you must, DiffServ on your routers and switches.

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.

  1. H.245 negotiates the codec and establishes RTP sockets that will be used on either end of the media channel. These two socketsthe IP addresses and port numberstogether form the session ID that RSVP will use to refer to this RTP session. RSVP calls the session ID a flow ID .

  2. The gateway router for the caller, B in Figure 9-5, sends a path message (PM) to the next hop, B, along the way to the remote gateway router, D. This PM will continue to be forwarded from one hop to the next in order to establish the QoS path.

  3. B records the latency added as the PM reaches it, along with minimum latency, jitter ranges the router is willing to guarantee. Then, the PM is sent to the next router along the path, in this case, C.

  4. C records the latency added as the PM reaches it, along with minimum latency, jitter ranges the router is willing to guarantee. Then, the PM is sent to the next router along the path, in this case, D.

  5. When the PM reaches the remote gateway router, D, cumulative latency and jitter are calculated. The result is a profile call the ADSPEC, and the portion of the RSVP header used to accumulate QoS data during the PM is called the ADSPEC header.

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 hop

When the remote gateway router reads the ADSPEC data and makes the determination, it can do one of two things:

  • Give up, resulting in a busy tone for the caller

  • Trigger the reserve message (RM) to set up the traffic contracts with each router in order to reserve bandwidth for the call

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:

  1. The remote gateway router (D) sends the reserve message to the previous router in the path. The sender and receiver RTP sockets are confirmed, and a contract is established for the timeout value in seconds, sustained throughput, and peak throughput required by the RTP session.

  2. The previous router in the path (C) sends a similar RM to its previous router in the path (B).

  3. Router B sends router A another RM.

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:

  1. Router A sends a reserve confirm message to router B if it agrees to guarantee the bandwidth and timeout values requested , or a rejection message if not.

  2. Router B sends router C a similar response. If the first response, from router A, was a rejection, then all subsequent responses will be rejections as well.

  3. Router C sends router D a similar response. If the first or second was a rejection, then this response will be a rejection as well.

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.") Controlled loads versus guarantees

RSVP defines three service levels in RFC 2211:

Best Effort

A class of service that has no QoS measures whatsoever, wherein RSVP ADSPECs and RMs can be used to collect data about network conditions but not actually enforce any bandwidth allocations . On Cisco routers, the fair-queuing feature is used to enable Best Effort service.

Controlled Load

More like CoS, Controlled Load allows prioritization of traffic over multiple routers like DiffServ but includes core routers in the decision-making process.


The ultimate application for RSVP, Guaranteed means that no packets will be lost, bandwidth will be constant, and delay will be within the prescribed ranges set up in the traffic contract.

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.

Project 9.2, later in this chapter, shows how to tell whether all the routers on a certain call path support RSVP.

RSVP has the following general characteristics:

  • Is enforced with routers like DiffServ

  • Can run transparently alongside other QoS solutionsespecially 802.1p

  • Is intended for networks with limited through bandwidth or networks with voice traffic typically greater than its non-voice traffic

  • Can be optionally policy based

  • Keeps QoS decisions to the core of the network and therefore has more complex signaling than DiffServ

  • Is compatible with IPv4 and IPv6

All I Have Is a Single Office LAN! Do I Really Need All This QoS?

Merely enabling IP precedence/ToS on a stack of Ethernet switches will take care of almost all quality problems in a LAN-only setup. As long as the local area network isn't swamped with voice traffic, IP precedence and ToS are all you really need. That's good newsjust about all modern Ethernet switches support them.

For point-to-point WAN links, IP precedence can work as long as the link isn't swamped with voice traffic. But, since these links offer far less bandwidth than a LAN, they have a tendency to get filled from time to time. If your routers are set to enforce IP precedence tags and you're still having audio problems, check your dial-plan to make sure the right codecs are being used so you're not wasting bandwidth over the link. And if all this doesn't solve your problem, a half-day visit from your local Cisco router engineer should get RSVP up and running.

9.5.2. MPLS

Multiprotocol 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.

For small- to mid- size VoIP networks with a few hundred endpoints, you can safely forego MPLS switching. MPLS is aimed at networks that operate with extremely high volumes of real-time traffic. Use MPLS switching in environments with carrier-grade requirements or thousands of endpoints.

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:

MPLS has the following general characteristics:

  • Is usually managed with switches

  • Can run transparently within other labeled switching solutions such as ATM

  • Is intended for carrier-grade networks

  • Mimics ATM in function, but can be used across a variety of non-ATM networks, such as TCP/IP

  • Is the most flexible, and the most sophisticated, QoS mechanism for VoIP systems

Switching to VoIP
Switching to VoIP
ISBN: 0596008686
EAN: 2147483647
Year: 2005
Pages: 172

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: