12.3 Adding QoS to Frame and IP

---

Unlike ATM, frame relay and IP do not inherently support QoS—protocols must be added in order to prioritize different types of traffic for appropriate handling through the network. Most routers today can add prioritization schemes to expedite the delivery of real-time traffic over frame relay (see Table 12.2) and IP (see Table 12.3) using standard or proprietary mechanisms. However, with so many devices on these types of networks, IT staff can easily get bogged down performing manual QoS configurations to fully optimize the enterprise network. This task can be less tedious and error prone by using policy-based network management solutions.

Table 12.2: Selected QoS Mechanisms for Frame Relay Networks QoS Mechanism Description Applications

QoS Mechanism	Description	Applications
Rate enforcement on a per-VC basis	The peak rate value for outbound traffic can be set to match the CIR to provide a CBR.	Suited for real-time applications such as voice, streaming data, and large file transfers.
Dynamic traffic throttling on a per-VC basis	When BECN packets indicate congestion on the network, the outbound traffic rate is automatically stepped down by 25%; when congestion eases, the outbound traffic rate is allowed to increase.	This network function ensures that all or outgoing CIR during times of congestion. Routers that do not respond to BECN risk having their traffic discarded.
Enhanced queuing support on a per-VC basis	Either custom queuing or priority output queuing can be configured for VCs.	Custom queuing is used in environments that need to guarantee a minimal level of service to all applications. Priority output queuing is used to give mission-critical data the highest priority and hold back less-critical traffic during periods of congestion.

Table 12.3: Selected QoS Mechanisms for TCP/IP Networks QoS Mechanism Description Applications

QoS Mechanism	Description	Applications
RSVP	Sets up resources through the network to deliver the data stream to each router on the network that has attached subscribers who have preregistered to receive it.	Suited for real-time applications such as scheduled audio/video multicasts, computer-based training (CBT), and distance learning.
PIM*	Sends the data stream only once from the server, which is replicated at an RP only as many times as necessary to reach the nearest subscribers who have registered to receive it.	Handles same applications as RSVP but is more bandwidth-efficient than RSVP. PIM also conserves processing resources at the server, since the stream goes out to the network only once.
RTP*	Sequentially tags IP packets to enable proper reassembly of the packet stream at the receiving endpoint before conversion to the real-time application.	Handles real-time, multicast, and simulation applications but does not set up network resources as do RSVP and PIM. RTP is augmented by Real Time Control Protocol (RTCP) to allow monitoring of data delivery and provide minimal control and identification functionality.
IP Precedence	Expedites the handling of IP packets based on the partitioning of the traffic into as many as six classes that can be indicated in the type of service (ToS) field of the IPv4 header.	Handles a range of real-time and nontimesensitive applications based on the class of service they are assigned.
Diff-Serv	Supersedes the original IP precedence specification for defining packet priority. Diff-Serv first prioritizes traffic by class, then differentiates and prioritizes same-class traffic, offering finer priority granularity.	Satisfies differing services and applications based on the QoS specified by each packet.

*By themselves, PIM and RTP are not really QoS mechanisms, but they are often used with other protocols such as RSVP and Diff-Serv to achieve QoS.

---