rfc2474.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/4 页

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]