McDewey

Multi-vendor documentation library · semantic search · MCP endpoint at /mcp

Page 17

↗ View in doc context
page
17
source
voice-quality/troubleshooting/qos-voip-solutions/qos-voip-solutions.md
chunk_id
voice-quality::troubleshooting::qos-voip-solutions::qos-voip-solutions::16

Quality of Service for Voice over IP Differentiated Services for VoIP 17 QoSVoIP.mif Differentiated Services for VoIP The Differentiated Services (DS) architecture QoS model provides a scalable mechanism to classify packets into groups or classes that have similar QoS requirements. This section describes DS and includes the following subsections: • DS and the DSCP (RFC 2474, RFC 2475) Overview • Implementing DS for VoIP: Expedited Forwarding PHB (RFC 2598) • DSCP Class-Based Marking Configuration Example DS and the DSCP (RFC 2474, RFC 2475) Overview The first IP networks were based on the best-effort service model, which meant that delay, jitter, packet loss, and bandwidth allocation were unpredictable. Today a large number of networks still follow this best-effort model and do not support enhanced applications that require some sort of service guarantee. Using the best-effort model, service providers have no means of offering service level agreements (SLAs) to their customers other than overprovisioning their network to deal with the busiest traffic hours. Enterprise customers and end users have no way of providing priority treatment or guaranteed bandwidth for VoIP. Traffic is treated on a simple, FIFO basis with no QoS enforcement. The first architectural approach to providing end-to-end QoS required that the application signal its QoS resource requirements (such as bandwidth and guaranteed delay) to the network. In a VoIP scenario, this architectural approach meant that either the IP telephone or voice gateway needed to make QoS requests to every hop in the network so that end-to-end resources would be allocated. Every hop needed to maintain call state information to determine when to release the QoS resources for other calls and applications, and if enough resources were available, to accept calls with QoS guarantees. This method is called the Integrated Services QoS model. The most common implementation of Integrated Services uses Resource Reservation Protocol (RSVP). RSVP has some advantages, such as Call Admission Control (CAC), where a call can be rerouted by sending an appropriate signal to the originator if the network does not have the QoS resources available to support it. However, RSVP also suffers from some scalability issues; RSVP and those issues are discussed later in this document. The DS architecture is the most widely deployed and supported QoS model today. It provides a scalable mechanism to classify packets into groups or classes that have similar QoS requirements and then gives these groups the required treatment at every hop in the network. The scalability comes from the fact that packets are classified at the edges of the DS “cloud” or region and marked appropriately so that the core routers in the cloud can provide QoS based simply on the DS class. The six most significant bits of the IP Type of Service (ToS) byte are used to specify the DS class; the Differentiated Services Code Point (DSCP) defines these six bits. The remaining two bits in the IP ToS byte are currently unused. Figure 5 shows how the IP header defines the DS class.