Network Working Group
`Request for Comments: 2474
`Obsoletes: 1455, 1349
`Category: Standards Track
`
`K. Nichols
`Cisco Systems
`S. Blake
`Torrent Networking Technologies
`F. Baker
`Cisco Systems
`D. Black
`EMC Corporation
`December 1998
`
` Definition of the Differentiated Services Field (DS Field)
`in the IPv4 and IPv6 Headers
`
`Status of this Memo
`
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Copyright Notice
`
` Copyright (C) The Internet Society (1998). All Rights Reserved.
`
`Abstract
`
` Differentiated services enhancements to the Internet protocol are
` intended to enable scalable service discrimination in the Internet
` without the need for per-flow state and signaling at every hop. A
` variety of services may be built from a small, well-defined set of
` building blocks which are deployed in network nodes. The services
` may be either end-to-end or intra-domain; they include both those
` that can satisfy quantitative performance requirements (e.g., peak
` bandwidth) and those based on relative performance (e.g., "class"
` differentiation). Services can be constructed by a combination of:
`
`- setting bits in an IP header field at network boundaries
`(autonomous system boundaries, internal administrative boundaries,
`or hosts),
`- using those bits to determine how packets are forwarded by the
`nodes inside the network, and
`- conditioning the marked packets at network boundaries in accordance
`with the requirements or rules of each service.
`
`Nichols, et. al.
`
`Standards Track
`
`[Page 1]
`
`EX1020
`Palo Alto Networks v. Sable Networks
`IPR2021-00051
`
`

`

`
`RFC 2474 Differentiated Services Field December 1998
`
` The requirements or rules of each service must be set through
` administrative policy mechanisms which are outside the scope of this
` document. A differentiated services-compliant network node includes
` a classifier that selects packets based on the value of the DS field,
` along with buffer management and packet scheduling mechanisms capable
` of delivering the specific packet forwarding treatment indicated by
` the DS field value. Setting of the DS field and conditioning of the
` temporal behavior of marked packets need only be performed at network
` boundaries and may vary in complexity.
`
` This document defines the IP header field, called the DS (for
` differentiated services) field. In IPv4, it defines the layout of
` the TOS octet; in IPv6, the Traffic Class octet. In addition, a base
` set of packet forwarding treatments, or per-hop behaviors, is
` defined.
`
` For a more complete understanding of differentiated services, see
` also the differentiated services architecture [ARCH].
`
`Table of Contents
`
` 1. Introduction ................................................. 3
` 2. Terminology Used in This Document ............................ 5
` 3. Differentiated Services Field Definition ..................... 7
` 4. Historical Codepoint Definitions and PHB Requirements ........ 9
` 4.1 A Default PHB ............................................. 9
` 4.2 Once and Future IP Precedence Field Use ................... 10
` 4.2.1 IP Precedence History and Evolution in Brief .......... 10
` 4.2.2 Subsuming IP Precedence into Class Selector .......... 11
` Codepoints
` 4.2.2.1 The Class Selector Codepoints ..................... 11
` 4.2.2.2 The Class Selector PHB Requirements ............... 11
` 4.2.2.3 Using the Class Selector PHB Requirements ......... 12
` for IP Precedence Compatibility
` 4.2.2.4 Example Mechanisms for Implementing Class ......... 12
` Selector Compliant PHB Groups
` 4.3 Summary ................................................... 13
` 5. Per-Hop Behavior Standardization Guidelines .................. 13
` 6. IANA Considerations .......................................... 14
` 7. Security Considerations ...................................... 15
` 7.1 Theft and Denial of Service ............................... 15
` 7.2 IPsec and Tunneling Interactions .......................... 16
` 8. Acknowledgments .............................................. 17
` 9. References ................................................... 17
` Authors’ Addresses ............................................... 19
` Full Copyright Statement ......................................... 20
`
`Nichols, et. al. Standards Track [Page 2]
`
`

`

`
`RFC 2474 Differentiated Services Field December 1998
`
`1. Introduction
`
` Differentiated services are intended to provide a framework and
` building blocks to enable deployment of scalable service
` discrimination in the Internet. The differentiated services approach
` aims to speed deployment by separating the architecture into two
` major components, one of which is fairly well-understood and the
` other of which is just beginning to be understood. In this, we are
` guided by the original design of the Internet where the decision was
` made to separate the forwarding and routing components. Packet
` forwarding is the relatively simple task that needs to be performed
` on a per-packet basis as quickly as possible. Forwarding uses the
` packet header to find an entry in a routing table that determines the
` packet’s output interface. Routing sets the entries in that table
` and may need to reflect a range of transit and other policies as well
` as to keep track of route failures. Routing tables are maintained as
` a background process to the forwarding task. Further, routing is the
` more complex task and it has continued to evolve over the past 20
` years.
`
` Analogously, the differentiated services architecture contains two
` main components. One is the fairly well-understood behavior in the
` forwarding path and the other is the more complex and still emerging
` background policy and allocation component that configures parameters
` used in the forwarding path. The forwarding path behaviors include
` the differential treatment an individual packet receives, as
` implemented by queue service disciplines and/or queue management
` disciplines. These per-hop behaviors are useful and required in
` network nodes to deliver differentiated treatment of packets no
` matter how we construct end-to-end or intra-domain services. Our
` focus is on the general semantics of the behaviors rather than the
` specific mechanisms used to implement them since these behaviors will
` evolve less rapidly than the mechanisms.
`
` Per-hop behaviors and mechanisms to select them on a per-packet basis
` can be deployed in network nodes today and it is this aspect of the
` differentiated services architecture that is being addressed first.
` In addition, the forwarding path may require that some monitoring,
` policing, and shaping be done on the network traffic designated for
` "special" treatment in order to enforce requirements associated with
` the delivery of the special treatment. Mechanisms for this kind of
` traffic conditioning are also fairly well-understood. The wide
` deployment of such traffic conditioners is also important to enable
` the construction of services, though their actual use in constructing
` services may evolve over time.
`
`Nichols, et. al. Standards Track [Page 3]
`
`

`

`
`RFC 2474 Differentiated Services Field December 1998
`
` The configuration of network elements with respect to which packets
` get special treatment and what kinds of rules are to be applied to
` the use of resources is much less well-understood. Nevertheless, it
` is possible to deploy useful differentiated services in networks by
` using simple policies and static configurations. As described in
` [ARCH], there are a number of ways to compose per-hop behaviors and
` traffic conditioners to create services. In the process, additional
` experience is gained that will guide more complex policies and
` allocations. The basic behaviors in the forwarding path can remain
` the same while this component of the architecture evolves.
` Experiences with the construction of such services will continue for
` some time, thus we avoid standardizing this construction as it is
` premature. Further, much of the details of service construction are
` covered by legal agreements between different business entities and
` we avoid this as it is very much outside the scope of the IETF.
`
` This document concentrates on the forwarding path component. In the
` packet forwarding path, differentiated services are realized by
` mapping the codepoint contained in a field in the IP packet header to
` a particular forwarding treatment, or per-hop behavior (PHB), at each
` network node along its path. The codepoints may be chosen from a set
` of mandatory values defined later in this document, from a set of
` recommended values to be defined in future documents, or may have
` purely local meaning. PHBs are expected to be implemented by
` employing a range of queue service and/or queue management
` disciplines on a network node’s output interface queue: for example
` weighted round-robin (WRR) queue servicing or drop-preference queue
` management.
`
` Marking is performed by traffic conditioners at network boundaries,
` including the edges of the network (first-hop router or source host)
` and administrative boundaries. Traffic conditioners may include the
` primitives of marking, metering, policing and shaping (these
` mechanisms are described in [ARCH]). Services are realized by the
` use of particular packet classification and traffic conditioning
` mechanisms at boundaries coupled with the concatenation of per-hop
` behaviors along the transit path of the traffic. A goal of the
` differentiated services architecture is to specify these building
` blocks for future extensibility, both of the number and type of the
` building blocks and of the services built from them.
`
` Terminology used in this memo is defined in Sec. 2. The
` differentiated services field definition (DS field) is given in Sec.
` 3. In Sec. 4, we discuss the desire for partial backwards
` compatibility with current use of the IPv4 Precedence field. As a
` solution, we introduce Class Selector Codepoints and Class Selector
`
`Nichols, et. al. Standards Track [Page 4]
`
`

`

`
`RFC 2474 Differentiated Services Field December 1998
`
` Compliant PHBs. Sec. 5 presents guidelines for per-hop behavior
` standardization. Sec. 6 discusses guidelines for allocation of
` codepoints. Sec. 7 covers security considerations.
`
` This document is a concise description of the DS field and its uses.
` It is intended to be read along with the differentiated services
` architecture [ARCH].
`
` The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
` "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
` document are to be interpreted as described in [RFC2119].
`
`2. Terminology Used in This Document
`
` Behavior Aggregate: a collection of packets with the same codepoint
` crossing a link in a particular direction. The terms "aggregate" and
` "behavior aggregate" are used interchangeably in this document.
`
` Classifier: an entity which selects packets based on the content of
` packet headers according to defined rules.
`
` Class Selector Codepoint: any of the eight codepoints in the range ’
` xxx000’ (where ’x’ may equal ’0’ or ’1’). Class Selector Codepoints
` are discussed in Sec. 4.2.2.
`
` Class Selector Compliant PHB: a per-hop behavior satisfying the Class
` Selector PHB Requirements specified in Sec. 4.2.2.2.
`
` Codepoint: a specific value of the DSCP portion of the DS field.
` Recommended codepoints SHOULD map to specific, standardized PHBs.
` Multiple codepoints MAY map to the same PHB.
`
` Differentiated Services Boundary: the edge of a DS domain, where
` classifiers and traffic conditioners are likely to be deployed. A
` differentiated services boundary can be further sub-divided into
` ingress and egress nodes, where the ingress/egress nodes are the
` downstream/upstream nodes of a boundary link in a given traffic
` direction. A differentiated services boundary typically is found at
` the ingress to the first-hop differentiated services-compliant router
` (or network node) that a host’s packets traverse, or at the egress of
` the last-hop differentiated services-compliant router or network node
` that packets traverse before arriving at a host. This is sometimes
` referred to as the boundary at a leaf router. A differentiated
` services boundary may be co-located with a host, subject to local
` policy. Also DS boundary.
`
` Differentiated Services-Compliant: in compliance with the
` requirements specified in this document. Also DS-compliant.
`
`Nichols, et. al. Standards Track [Page 5]
`
`

`

`
`RFC 2474 Differentiated Services Field December 1998
`
` Differentiated Services Domain: a contiguous portion of the Internet
` over which a consistent set of differentiated services policies are
` administered in a coordinated fashion. A differentiated services
` domain can represent different administrative domains or autonomous
` systems, different trust regions, different network technologies
` (e.g., cell/frame), hosts and routers, etc. Also DS domain.
`
` Differentiated Services Field: the IPv4 header TOS octet or the IPv6
` Traffic Class octet when interpreted in conformance with the
` definition given in this document. Also DS field.
`
` Mechanism: The implementation of one or more per-hop behaviors
` according to a particular algorithm.
`
` Microflow: a single instance of an application-to-application flow of
` packets which is identified by source address, destination address,
` protocol id, and source port, destination port (where applicable).
`
` Per-hop Behavior (PHB): a description of the externally observable
` forwarding treatment applied at a differentiated services-compliant
` node to a behavior aggregate. The description of a PHB SHOULD be
` sufficiently detailed to allow the construction of predictable
` services, as documented in [ARCH].
`
` Per-hop Behavior Group: a set of one or more PHBs that can only be
` meaningfully specified and implemented simultaneously, due to a
` common constraint applying to all PHBs in the set such as a queue
` servicing or queue management policy. Also PHB Group.
`
` Traffic Conditioning: control functions that can be applied to a
` behavior aggregate, application flow, or other operationally useful
` subset of traffic, e.g., routing updates. These MAY include
` metering, policing, shaping, and packet marking. Traffic
` conditioning is used to enforce agreements between domains and to
` condition traffic to receive a differentiated service within a domain
` by marking packets with the appropriate codepoint in the DS field and
` by monitoring and altering the temporal characteristics of the
` aggregate where necessary. See [ARCH].
`
` Traffic Conditioner: an entity that performs traffic conditioning
` functions and which MAY contain meters, policers, shapers, and
` markers. Traffic conditioners are typically deployed in DS boundary
` nodes (i.e., not in interior nodes of a DS domain).
`
` Service: a description of the overall treatment of (a subset of) a
` customer’s traffic across a particular domain, across a set of
` interconnected DS domains, or end-to-end. Service descriptions are
` covered by administrative policy and services are constructed by
`
`Nichols, et. al. Standards Track [Page 6]
`
`

`

`
`RFC 2474 Differentiated Services Field December 1998
`
` applying traffic conditioning to create behavior aggregates which
` experience a known PHB at each node within the DS domain. Multiple
` services can be supported by a single per-hop behavior used in
` concert with a range of traffic conditioners.
`
` To summarize, classifiers and traffic conditioners are used to select
` which packets are to be added to behavior aggregates. Aggregates
` receive differentiated treatment in a DS domain and traffic
` conditioners MAY alter the temporal characteristics of the aggregate
` to conform to some requirements. A packet’s DS field is used to
` designate the packet’s behavior aggregate and is subsequently used to
` determine which forwarding treatment the packet receives. A behavior
` aggregate classifier which can select a PHB, for example a
` differential output queue servicing discipline, based on the
` codepoint in the DS field SHOULD be included in all network nodes in
` a DS domain. The classifiers and traffic conditioners at DS
` boundaries are configured in accordance with some service
` specification, a matter of administrative policy outside the scope of
` this document.
`
` Additional differentiated services definitions are given in [ARCH].
`
`3. Differentiated Services Field Definition
`
` A replacement header field, called the DS field, is defined, which is
` intended to supersede the existing definitions of the IPv4 TOS octet
` [RFC791] and the IPv6 Traffic Class octet [IPv6].
`
` Six bits of the DS field are used as a codepoint (DSCP) to select the
` PHB a packet experiences at each node. A two-bit currently unused
` (CU) field is reserved and its definition and interpretation are
` outside the scope of this document. The value of the CU bits are
` ignored by differentiated services-compliant nodes when determining
` the per-hop behavior to apply to a received packet.
`
` The DS field structure is presented below:
`
` 0 1 2 3 4 5 6 7
` +---+---+---+---+---+---+---+---+
` | DSCP | CU |
` +---+---+---+---+---+---+---+---+
`
` DSCP: differentiated services codepoint
` CU: currently unused
`
`Nichols, et. al. Standards Track [Page 7]
`
`

`

`
`RFC 2474 Differentiated Services Field December 1998
`
` In a DSCP value notation ’xxxxxx’ (where ’x’ may equal ’0’ or ’1’)
` used in this document, the left-most bit signifies bit 0 of the DS
` field (as shown above), and the right-most bit signifies bit 5.
`
` Implementors should note that the DSCP field is six bits wide. DS-
` compliant nodes MUST select PHBs by matching against the entire 6-bit
` DSCP field, e.g., by treating the value of the field as a table index
` which is used to select a particular packet handling mechanism which
` has been implemented in that device. The value of the CU field MUST
` be ignored by PHB selection. The DSCP field is defined as an
` unstructured field to facilitate the definition of future per-hop
` behaviors.
`
` With some exceptions noted below, the mapping of codepoints to PHBs
` MUST be configurable. A DS-compliant node MUST support the logical
` equivalent of a configurable mapping table from codepoints to PHBs.
` PHB specifications MUST include a recommended default codepoint,
` which MUST be unique for codepoints in the standard space (see Sec.
` 6). Implementations should support the recommended codepoint-to-PHB
` mappings in their default configuration. Operators may choose to use
` different codepoints for a PHB, either in addition to or in place of
` the recommended default. Note that if operators do so choose, re-
` marking of DS fields may be necessary at administrative boundaries
` even if the same PHBs are implemented on both sides of the boundary.
`
` See [ARCH] for further discussion of re-marking.
`
` The exceptions to general configurability are for codepoints ’xxx000’
` and are noted in Secs. 4.2.2 and 4.3.
`
` Packets received with an unrecognized codepoint SHOULD be forwarded
` as if they were marked for the Default behavior (see Sec. 4), and
` their codepoints should not be changed. Such packets MUST NOT cause
` the network node to malfunction.
`
` The structure of the DS field shown above is incompatible with the
` existing definition of the IPv4 TOS octet in [RFC791]. The
` presumption is that DS domains protect themselves by deploying re-
` marking boundary nodes, as should networks using the RFC 791
` Precedence designations. Correct operational procedure SHOULD follow
` [RFC791], which states: "If the actual use of these precedence
` designations is of concern to a particular network, it is the
` responsibility of that network to control the access to, and use of,
` those precedence designations." Validating the value of the DS field
` at DS boundaries is sensible in any case since an upstream node can
` easily set it to any arbitrary value. DS domains that are not
` isolated by suitably configured boundary nodes may deliver
` unpredictable service.
`
`Nichols, et. al. Standards Track [Page 8]
`
`

`

`
`RFC 2474 Differentiated Services Field December 1998
`
` Nodes MAY rewrite the DS field as needed to provide a desired local
` or end-to-end service. Specifications of DS field translations at DS
` boundaries are the subject of service level agreements between
` providers and users, and are outside the scope of this document.
` Standardized PHBs allow providers to build their services from a
` well-known set of packet forwarding treatments that can be expected
` to be present in the equipment of many vendors.
`
`4. Historical Codepoint Definitions and PHB Requirements
`
` The DS field will have a limited backwards compatibility with current
` practice, as described in this section. Backwards compatibility is
` addressed in two ways. First, there are per-hop behaviors that are
` already in widespread use (e.g., those satisfying the IPv4 Precedence
` queueing requirements specified in [RFC1812]), and we wish to permit
` their continued use in DS-compliant nodes. In addition, there are
` some codepoints that correspond to historical use of the IP
` Precedence field and we reserve these codepoints to map to PHBs that
` meet the general requirements specified in Sec. 4.2.2.2, though the
` specific differentiated services PHBs mapped to by those codepoints
` MAY have additional specifications.
`
` No attempt is made to maintain backwards compatibility with the "DTR"
` or TOS bits of the IPv4 TOS octet, as defined in [RFC791].
`
`4.1 A Default PHB
`
` A "default" PHB MUST be available in a DS-compliant node. This is
` the common, best-effort forwarding behavior available in existing
` routers as standardized in [RFC1812]. When no other agreements are
` in place, it is assumed that packets belong to this aggregate. Such
` packets MAY be sent into a network without adhering to any particular
` rules and the network will deliver as many of these packets as
` possible and as soon as possible, subject to other resource policy
` constraints. A reasonable implementation of this PHB would be a
` queueing discipline that sends packets of this aggregate whenever the
` output link is not required to satisfy another PHB. A reasonable
` policy for constructing services would ensure that the aggregate was
` not "starved". This could be enforced by a mechanism in each node
` that reserves some minimal resources (e.g, buffers, bandwidth) for
` Default behavior aggregates. This permits senders that are not
` differentiated services-aware to continue to use the network in the
` same manner as today. The impact of the introduction of
` differentiated services into a domain on the service expectations of
` its customers and peers is a complex matter involving policy
` decisions by the domain and is outside the scope of this document.
` The RECOMMENDED codepoint for the Default PHB is the bit pattern ’
` 000000’; the value ’000000’ MUST map to a PHB that meets these
`
`Nichols, et. al. Standards Track [Page 9]
`
`

`

`
`RFC 2474 Differentiated Services Field December 1998
`
` specifications. The codepoint chosen for Default behavior is
` compatible with existing practice [RFC791]. Where a codepoint is not
` mapped to a standardized or local use PHB, it SHOULD be mapped to the
` Default PHB.
`
` A packet initially marked for the Default behavior MAY be re-marked
` with another codepoint as it passes a boundary into a DS domain so
` that it will be forwarded using a different PHB within that domain,
` possibly subject to some negotiated agreement between the peering
` domains.
`
`4.2 Once and Future IP Precedence Field Use
`
` We wish to maintain some form of backward compatibility with present
` uses of the IP Precedence Field: bits 0-2 of the IPv4 TOS octet.
` Routers exist that use the IP Precedence field to select different
` per-hop forwarding treatments in a similar way to the use proposed
` here for the DSCP field. Thus, a simple prototype differentiated
` services architecture can be quickly deployed by appropriately
` configuring these routers. Further, IP systems today understand the
` location of the IP Precedence field, and thus if these bits are used
` in a similar manner as DS-compliant equipment is deployed,
` significant failures are not likely during early deployment. In
` other words, strict DS-compliance need not be ubiquitous even within
` a single service provider’s network if bits 0-2 of the DSCP field are
` employed in a manner similar to, or subsuming, the deployed uses of
` the IP Precedence field.
`
`4.2.1 IP Precedence History and Evolution in Brief
`
` The IP Precedence field is something of a forerunner of the DS field.
` IP Precedence, and the IP Precedence Field, were first defined in
` [RFC791]. The values that the three-bit IP Precedence Field might
` take were assigned to various uses, including network control
` traffic, routing traffic, and various levels of privilege. The least
` level of privilege was deemed "routine traffic". In [RFC791], the
` notion of Precedence was defined broadly as "An independent measure
` of the importance of this datagram." Not all values of the IP
` Precedence field were assumed to have meaning across boundaries, for
` instance "The Network Control precedence designation is intended to
` be used within a network only. The actual use and control of that
` designation is up to each network." [RFC791]
`
` Although early BBN IMPs implemented the Precedence feature, early
` commercial routers and UNIX IP forwarding code generally did not. As
` networks became more complex and customer requirements grew,
` commercial router vendors developed ways to implement various kinds
` of queueing services including priority queueing, which were
`
`Nichols, et. al. Standards Track [Page 10]
`
`

`

`
`RFC 2474 Differentiated Services Field December 1998
`
` generally based on policies encoded in filters in the routers, which
` examined IP addresses, IP protocol numbers, TCP or UDP ports, and
` other header fields. IP Precedence was and is among the options such
` filters can examine.
`
` In short, IP Precedence is widely deployed and widely used, if not in
` exactly the manner intended in [RFC791]. This was recognized in
` [RFC1122], which states that while the use of the IP Precedence field
` is valid, the specific assignment of the priorities in [RFC791] were
` merely historical.
`
`4.2.2 Subsuming IP Precedence into Class Selector Codepoints
`
` A specification of the packet forwarding treatments selected by the
` IP Precedence field today would have to be quite general; probably
` not specific enough to build predictable services from in the
` differentiated services framework. To preserve partial backwards
` compatibility with known current uses of the IP Precedence field
` without sacrificing future flexibility, we have taken the approach of
` describing minimum requirements on a set of PHBs that are compatible
` with most of the deployed forwarding treatments selected by the IP
` Precedence field. In addition, we give a set of codepoints that MUST
` map to PHBs meeting these minimum requirements. The PHBs mapped to
` by these codepoints MAY have a more detailed list of specifications
` in addition to the required ones stated here. Other codepoints MAY
` map to these same PHBs. We refer to this set of codepoints as the
` Class Selector Codepoints, and the minimum requirements for PHBs that
` these codepoints may map to are called the Class Selector PHB
` Requirements.
`
`4.2.2.1 The Class Selector Codepoints
`
` A specification of the packet forwarding treatments selected by the
` The DS field values of ’xxx000|xx’, or DSCP = ’xxx000’ and CU
` subfield unspecified, are reserved as a set of Class Selector
` Codepoints. PHBs which are mapped to by these codepoints MUST
` satisfy the Class Selector PHB requirements in addition to preserving
` the Default PHB requirement on codepoint ’000000’ (Sec. 4.1).
`
`4.2.2.2 The Class Selector PHB Requirements
`
` We refer to a Class Selector Codepoint with a larger numerical value
` than another Class Selector Codepoint as having a higher relative
` order while a Class Selector Codepoint with a smaller numerical value
` than another Class Selector Codepoint is said to have a lower
` relative order. The set of PHBs mapped to by the eight Class
` Selector Codepoints MUST yield at least two independently forwarded
` classes of traffic, and PHBs selected by a Class Selector Codepoint
`
`Nichols, et. al. Standards Track [Page 11]
`
`

`

`
`RFC 2474 Differentiated Services Field December 1998
`
` SHOULD give packets a probability of timely forwarding that is not
` lower than that given to packets marked with a Class Selector
` codepoint of lower relative order, under reasonable operating
` conditions and traffic loads. A discarded packet is considered to be
` an extreme case of untimely forwarding. In addition, PHBs selected
` by codepoints ’11x000’ MUST give packets a preferential forwarding
` treatment by comparison to the PHB selected by codepoint ’000000’ to
` preserve the common usage of IP Precedence values ’110’ and ’111’ for
` routing traffic.
`
` Further, PHBs selected by distinct Class Selector Codepoints SHOULD
` be independently forwarded; that is, packets marked with different
` Class Selector Codepoints MAY be re-ordered. A network node MAY
` enforce limits on the amount of the node’s resources that can be
` utilized by each of these PHBs.
`
` PHB groups whose specification satisfy these requirements are
` referred to as Class Selector Compliant PHBs.
`
` The Class Selector PHB Requirements on codepoint ’000000’ are
` compatible with those listed for the Default PHB in Sec. 4.1.
`
`4.2.2.3 Using the Class Selector PHB Requirements for IP Precedence
` Compatibility
`
` A DS-compliant network node can be deployed with a set of one or more
` Class Selector Compliant PHB groups. This document states that the
` set of codepoints ’xxx000’ MUST map to such a set of PHBs. As it is
` also possible to map multiple codepoints to the same PHB, the vendor
` or the network administrator MAY configure the network node to map
` codepoints to PHBs irrespective of bits 3-5 of the DSCP field to
` yield a network that is compatible with historical IP Precedence use.
` Thus, for example, codepoint ’011010’ would map to the same PHB as
` codepoint ’011000’.
`
`4.2.2.4 Example Mechanisms for Implementing Class Selector Compliant
` PHB Groups
`
` Class Selector Compliant PHBs can be realized by a variety of
` mechanisms, including strict priority queueing, weighted fair
` queueing (WFQ), WRR, or variants [RPS, HPFQA, DRR], or Class-Based
` Queuing [CBQ]. The distinction between PHBs and mechanisms is
` described in more detail in Sec. 5.
`
` It is important to note that these mechanisms might be available
` through other PHBs (standardized or not) that are available in a
` particular vendor’s equipment. For example, future documents may
` standardize a Strict Priority Queueing PHB group for a set of
`
`Nichols, et. al. Standards Track