rfc2474.txt

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

Network Working Group                                         K. Nichols
Request for Comments: 2474                                 Cisco Systems
Obsoletes: 1455, 1349                                           S. Blake
Category: Standards Track                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]

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.