DSCP is backward compatible with IP precedence

At the network layer, IP packets are typically classified based on source or destination IP address, packet length, or the contents of the ToS byte. Link-layer media often changes as a packet travels from its source to its destination. Because a CoS field does not exist in a standard Ethernet frame, CoS markings at the link layer are not preserved as packets traverse non-trunked or non-Ethernet the network. Using marking at the network layer (Layer 3) provides a more permanent marker that is preserved from source to destination. Originally, only the first three bits of the ToS byte were used for marking, referred to as IP precedence. However, newer standards have made the use of IP Precedence obsolete in favor of using the first 6-bits of the ToS byte for marking, referred to as DSCP.

The header of an IPv4 packet contains the ToS byte. IP precedence uses three precedence bits in the ToS field of the IPv4 header to specify CoS for each packet. IP precedence values range from 0 to 7 and allow you to partition traffic in up to six useable classes of service. (Settings 6 and 7 are reserved for internal network use.)

Differentiated Services (DiffServ) is a new model that supersedes—and is backward compatible with—IP precedence. DiffServ redefines the ToS byte and uses six prioritization bits that permit classification of up to 64 values (0 to 63), of which 32 are commonly used. A DiffServ value is called a DSCP.

With DiffServ, packet classification is used to partition network traffic into multiple priority levels or classes of service. Packet classification uses the DSCP traffic descriptor to categorize a packet within a specific group to define that packet. After the packet has been defined (classified), the packet is then accessible for QoS handling on the network.

This topic describes data-link-layer to network-layer interoperability between different QoS markers.

Mapping CoS to Network-Layer QoS

IP headers are preserved end to end when IP packets are transported across a network; datalink-layer headers are not preserved. This means that the IP layer is the most logical place to mark packets for end-to-end QoS. However, there are edge devices that can only mark frames at the data-link layer, and there are many other network devices that only operate at the datalink layer. To provide true end-to-end QoS, the ability to map QoS marking between the datalink layer and the network layer is essential.

Enterprise networks typically consist of a number of remote sites connected to the headquarters campus via a WAN. Remote sites typically consist of a switched LAN, and the headquarters campus network is both routed and switched. Providing end-to-end QoS through such an environment requires that CoS markings that are set at the LAN edge be mapped into QoS markings (such as IP precedence or DSCP) for transit through Campus or WAN routers. Campus and WAN routers can also map the QoS markings to new data-link headers for transit across the LAN. In this way, QoS can be preserved and uniformly applied across the enterprise.

Service providers offering IP services have a requirement to provide robust QoS solutions to their customers. The ability to map network-layer QoS to link-layer CoS allows these providers to offer a complete end-to-end QoS solution that does not depend on any specific link-layer technology.

Compatibility between an MPLS transport-layer and network-layer QoS is also achieved by mapping between MPLS experimental (EXP) bits and the IP precedence or DSCP bits. A service provider can map the customer network-layer QoS marking as-is, or change it to fit an agreed upon service level agreement (SLA). The information in the MPLS EXP bits can be carried end-to-end in the MPLS network, independent of the transport media. In addition, the network layer marking can remain unchanged so that when the packet leaves the service provider MPLS network, the original QoS markings remain intact. Thus, a service provider with an MPLS network can help provide a true end-to-end QoS solution.

This topic describes QoS service class and how service classes can be used to create a service policy throughout a network.

When an administrative policy requiring QoS is created, you must determine how network traffic is to be treated. As part of that policy definition, network traffic must be associated with a specific service class. QoS classification mechanisms are used to separate traffic and identify packets as belonging to a specific service class. QoS marking mechanisms are used to tag each packet as belonging to the assigned service class. After the packets are identified as belonging to a specific service class, QoS mechanisms such as policing, shaping, and queuing techniques can be applied to each service class to meet the specifications of the administrative policy. Packets belonging to the same service class are given the same treatment with regards to QoS.

A QoS service class, being a logical grouping, can be defined in many ways, including these:

■ Organization or department (marketing, engineering, sales, and so on)

■ A specific customer or set of customers

■ Specific applications or set of applications (Telnet, FTP, voice, Service Advertising Protocol [SAP], Oracle, video, and so on)

■ Specific users or sets of users (based on MAC address, IP address, LAN port, and so on)

■ Specific network destinations (tunnel interfaces, Virtual Private Networks [VPNs], and so on)

Was this article helpful?

0 0

Post a comment