RFC2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers的双语版

RFC2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers英文版

来源：http://www.hackhome.com/InfoView/127892_full.html

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.

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

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.

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

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.

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

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

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 RFC791
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.

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

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

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 'xxx000xx', 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

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

recommended codepoints. A network administrator might configure
those routers to select the Strict Priority Queueing PHBs with
codepoints 'xxx000' in conformance with the requirements of this
document.

As a further example, another vendor might employ a CBQ mechanism in
its routers. The CBQ mechanism could be used to implement the Strict
Priority Queueing PHBs as well as a set of Class Selector Compliant
PHBs with a wider range of features than would be available in a set
of PHBs that did no more than meet the minimum Class Selector PHB
requirements.

4.3 Summary

This document defines codepoints 'xxx000' as the Class Selector
codepoints, where PHBs selected by these codepoints MUST meet the
Class Selector PHB Requirements described in Sec. 4.2.2.2. This is
done to preserve a useful level of backward compatibility with
current uses of the IP Precedence field in the Internet without
unduly limiting future flexibility. In addition, codepoint '000000'
is used as the Default PHB value for the Internet and, as such, is
not configurable. The remaining seven non-zero Class Selector
codepoints are configurable only to the extent that they map to PHBs
that meet the requirements in Sec. 4.2.2.2.

5. Per-Hop Behavior Standardization Guidelines

The behavioral characteristics of a PHB are to be standardized, and
not the particular algorithms or the mechanisms used to implement
them. A node may have a (possibly large) set of parameters that can
be used to control how packets are scheduled onto an output interface
(e.g., N separate queues with settable priorities, queue lengths,
round-robin weights, drop algorithm, drop preference weights and
thresholds, etc). To illustrate the distinction between a PHB and a
mechanism, we point out that Class Selector Compliant PHBs might be
implemented by several mechanisms, including: strict priority
queueing, WFQ, WRR, or variants [HPFQA, RPS, DRR], or CBQ [CBQ], in
isolation or in combination.

PHBs may be specified individually, or as a group (a single PHB is a
special case of a PHB group). A PHB group usually consists of a set
of two or more PHBs that can only be meaningfully specified and
implemented simultaneously, due to a common constraint applying to
each PHB within the group, such as a queue servicing or queue
management policy. A PHB group specification SHOULD describe
conditions under which a packet might be re-marked to select another
PHB within the group. It is RECOMMENDED that PHB implementations do
not introduce any packet re-ordering within a microflow. PHB group

specifications MUST identify any possible packet re-ordering
implications which may occur for each individual PHB, and which may
occur if different packets within a microflow are marked for
different PHBs within the group.

Only those per-hop behaviors that are not described by an existing
PHB standard, and have been implemented, deployed, and shown to be
useful, SHOULD be standardized. Since current experience with
differentiated services is quite limited, it is premature to
hypothesize the exact specification of these per-hop behaviors.

Each standardized PHB MUST have an associated RECOMMENDED codepoint,
allocated out of a space of 32 codepoints (see Sec. 6). This
specification has left room in the codepoint space to allow for
evolution, thus the defined space ('xxx000') is intentionally sparse.

Network equipment vendors are free to offer whatever parameters and
capabilities are deemed useful or marketable. When a particular,
standardized PHB is implemented in a node, a vendor MAY use any
algorithm that satisfies the definition of the PHB according to the
standard. The node's capabilities and its particular configuration
determine the different ways that packets can be treated.

Service providers are not required to use the same node mechanisms or
configurations to enable service differentiation within their
networks, and are free to configure the node parameters in whatever
way that is appropriate for their service offerings and traffic
engineering objectives. Over time certain common per-hop behaviors
are likely to evolve (i.e., ones that are particularly useful for
implementing end-to-end services) and these MAY be associated with
particular EXP/LU PHB codepoints in the DS field, allowing use across
domain boundaries (see Sec. 6). These PHBs are candidates for future
standardization.

It is RECOMMENDED that standardized PHBs be specified in accordance
with the guidelines set out in [ARCH].

6. IANA Considerations

The DSCP field within the DS field is capable of conveying 64
distinct codepoints. The codepoint space is divided into three pools
for the purpose of codepoint assignment and management: a pool of 32
RECOMMENDED codepoints (Pool 1) to be assigned by Standards Action as
defined in [CONS], a pool of 16 codepoints (Pool 2) to be reserved
for experimental or Local Use (EXP/LU) as defined in [CONS], and a
pool of 16 codepoints (Pool 3) which are initially available for
experimental or local use, but which should be preferentially

utilized for standardized assignments if Pool 1 is ever exhausted.
The pools are defined in the following table (where 'x' refers to
either '0' or '1'):

Pool Codepoint space Assignment Policy
---- --------------- -----------------

1 xxxxx0 Standards Action
2 xxxx11 EXP/LU
3 xxxx01 EXP/LU (*)

(*) may be utilized for future Standards Action allocations as
necessary

This document assigns eight RECOMMENDED codepoints ('xxx000') which
are drawn from Pool 1 above. These codepoints MUST be mapped, not to
specific PHBs, but to PHBs that meet "at least" the requirements set
forth in Sec. 4.2.2.2 to provide a minimal level of backwards
compatibility with IP Precedence as defined in [RFC791] and as
deployed in some current equipment.

7. Security Considerations

This section considers security issues raised by the introduction of
differentiated services, primarily the potential for denial-of-
service attacks, and the related potential for theft of service by
unauthorized traffic (Section 7.1). Section 7.2 addresses the
operation of differentiated services in the presence of IPsec
including its interaction with IPsec tunnel mode and other tunnelling
protocols. See [ARCH] for more extensive treatment of the security
concerns raised by the overall differentiated services architecture.

7.1 Theft and Denial of Service

The primary goal of differentiated services is to allow different
levels of service to be provided for traffic streams on a common
network infrastructure. A variety of techniques may be used to
achieve this, but the end result will be that some packets receive
different (e.g., better) service than others. The mapping of network
traffic to the specific behaviors that result in different (e.g.,
better or worse) service is indicated primarily by the DS codepoint,
and hence an adversary may be able to oBTain better service by
modifying the codepoint to values indicating behaviors used for
enhanced services or by injecting packets with such codepoint values.
Taken to its limits, such theft-of-service becomes a denial-of-
service attack when the modified or injected traffic depletes the
resources available to forward it and other traffic streams.

The defense against this class of theft- and denial-of-service
attacks consists of the combination of traffic conditioning at DS
domain boundaries with security and integrity of the network
infrastructure within a DS domain. DS domain boundary nodes MUST
ensure that all traffic entering the domain is marked with codepoint
values appropriate to the traffic and the domain, remarking the
traffic with new codepoint values if necessary. These DS boundary
nodes are the primary line of defense against theft- and denial-of-
service attacks based on modified codepoints, as success of any such
attack indicates that the codepoints used by the attacking traffic
were inappropriate. An important instance of a boundary node is that
any traffic-originating node within a DS domain is the initial
boundary node for that traffic. Interior nodes in a DS domain rely
on DS codepoints to associate traffic with the forwarding PHBs, and
are NOT REQUIRED to check codepoint values before using them. As a
result, the interior nodes depend on the correct operation of the DS
domain boundary nodes to prevent the arrival of traffic with
inappropriate codepoints or in excess of provisioned levels that
would disrupt operation of the domain.

7.2 IPsec and Tunnelling Interactions

The IPsec protocol, as defined in [ESP, AH], does not include the IP
header's DS field in any of its cryptographic calculations (in the
case of tunnel mode, it is the outer IP header's DS field that is not
included). Hence modification of the DS field by a network node has
no effect on IPsec's end-to-end security, because it cannot cause any
IPsec integrity check to fail. As a consequence, IPsec does not
provide any defense against an adversary's modification of the DS
field (i.e., a man-in-the-middle attack), as the adversary's
modification will also have no effect on IPsec's end-to-end security.

IPsec's tunnel mode provides security for the encapsulated IP
header's DS field. A tunnel mode IPsec packet contains two IP
headers: an outer header supplied by the tunnel ingress node and an
encapsulated inner header supplied by the original source of the
packet. When an IPsec tunnel is hosted (in whole or in part) on a
differentiated services network, the intermediate network nodes
operate on the DS field in the outer header. At the tunnel egress
node, IPsec processing includes removing the outer header and
forwarding the packet (if required) using the inner header. The
IPsec protocol REQUIRES that the inner header's DS field not be
changed by this decapsulation processing to ensure that modifications
to the DS field cannot be used to launch theft- or denial-of-service
attacks across an IPsec tunnel endpoint. This document makes no
change to that requirement. If the inner IP header has not been
processed by a DS boundary node for the tunnel egress node's DS

domain, the tunnel egress node is the boundary node for traffic
exiting the tunnel, and hence MUST ensure that the resulting traffic
has appropriate DS codepoints.

When IPsec tunnel egress decapsulation processing includes a
sufficiently strong cryptographic integrity check of the encapsulated
packet (where sufficiency is determined by local security policy),
the tunnel egress node can safely assume that the DS field in the
inner header has the same value as it had at the tunnel ingress node.
An important consequence is that otherwise insecure links within a DS
domain can be secured by a sufficiently strong IPsec tunnel. This
analysis and its implications apply to any tunnelling protocol that
performs integrity checks, but the level of assurance of the inner
header's DS field depends on the strength of the integrity check
performed by the tunnelling protocol. In the absence of sufficient
assurance for a tunnel that may transit nodes outside the current DS
domain (or is otherwise vulnerable), the encapsulated packet MUST be
treated as if it had arrived at a boundary from outside the DS
domain.

8. Acknowledgements

The authors would like to acknowledge the Differentiated Services
Working Group for discussions which helped shape this document.

9. References

[AH] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC2402, November 1998.

[ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC2475, December 1998.

[CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource
Management Models for Packet Networks", IEEE/ACM
Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
August 1995.

[CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC2434, October
1998.

[DRR] M. Shreedhar and G. Varghese, Efficient Fair Queueing
using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995.

[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC2406, November 1998.

[HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair
Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996.

[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC2460, December 1998.

[RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC791,
September 1981.

[RFC1122] Braden, R., "Requirements for Internet hosts -
communication layers", STD 3, RFC1122, October 1989.

[RFC1812] Baker, F., Editor, "Requirements for IP Version 4
Routers", RFC1812, June 1995.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.

[RPS] D. Stiliadis and A. Varma, "Rate-Proportional Servers: A
Design Methodology for Fair Queueing Algorithms", IEEE/
ACM Trans. on Networking, April 1998.

Authors' Addresses

Kathleen Nichols
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706

Phone: +1-408-525-4857
EMail: kmn@cisco.com

Steven Blake
Torrent Networking Technologies
3000 Aerial Center, Suite 140
Morrisville, NC 27560

Phone: +1-919-468-8466 x232
EMail: slblake@torrentnet.com

Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, CA 93111

Phone: +1-408-526-4257
EMail: fred@cisco.com

David L. Black
EMC Corporation
35 Parkwood Drive
Hopkinton, MA 01748

Phone: +1-508-435-1000 x76140
EMail: black_david@emc.com

Full Copyright Statement

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

RFC2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers中文版

来源：http://blog.chinaunix.net/uid-22012730-id-1805367.html

一.RFC2474(Pv4与IPv6包头中差分服务字段（DS Field）的定义)
摘要
差分业务作为互连网协议提出，目的在于：在不需要规定每一数据流的状况以及每一跳
都要有所动作的情况下，使得能够对可以升级的、有区别的要求进行区分对待。而不同的服
务类型可以从配置于网络节点中的小的、已定义了的构造块组中来构造。这些服务即可以是
端到端的，也可以是在整个与内（定义）的；他们包括那些能满足一定性能的要求（如峰值
带宽）也包括那些具有相对性的性能（如“等级”区分）。这些服务可由以下方式结合建立：
? 在网络边界处（自治区域边界，内部管理边界或各个主机）的IP包头中设置特定
比特；
? 用这些比特来决定网络内部的节点如何转发这些包；
? 在网络边界处，调节带有标记的包（的调度）使之与各个服务的要求或规则一致。
这些各种服务的要求与规则必须由管理策略机构来制定，而这超出了本文的范围。一个适
用于差分服务的网络节点包含有过滤器、缓冲管理与包调度机制。过滤器基于包头的DS字
段的值来选择包，协同缓冲管理与包调度机制按该值所对应的转发方式来发送包。DS字段
的设置与带有标志的包的调整训练只需在网络边界进行，而且在复杂性问题上有很大的区
别。
本文定义了IP包头一特定字段，我们称之为DS(为差分服务而定)字段。实际上，这个
字段在IPv4定义为TOS及服务类型比特组，而在IPv6中则对应为流标签字段。另外，本
文定义了一些基本的转发方式，如“单段行为”（PHB）。
若想更完整的了解差分服务，请参阅“区分服务结构框架”[ARCH]。

目录

1. 导言 2
2. 本文所用术语 4
3. DS字段的定义 5
4. 从前的码值定义与PHB需求 6
4.1默认PHB 6
4.3 总结 9
5. 单段行为的标准化指南 9
6. IANA考虑 10
7. 安全性考虑 11
7.1盗用与拒绝差分服务 11
7.2   与IPsec和隧道技术的交互 11
8. 致谢 12
9. 参考资料 12
10. 作者地址 13
11. 版权陈述 14

1. 导言

差分服务的意图在于在因特网中配置一种能够对可以升级的、有区别的要求进行区分对
待的网络框架与区块构造。差分服务的目标是将整个构造系统分为两个主要部分来加速这种
配置的展开。这两部分一个相当容易理解，另一个我们才刚开始去理解。在这方面，我们以
一种起初构造因特网时的思想作为指导，即将转发与路由部件分离。包转发机制是一个相对
容易的工作，它只需要尽快的将每一个IP包转发出去。转发时，找到与包头所指对应的路
由表项来决定该包的输出接口。而路由要设置路由表中表项，而且要对一定范围内的有关变
化与其他一些情况如跟踪失败路由作出反应。路由表的维护是作为转发工作的背景程序进行
的。进一步说，路由这一复杂的问题今天已经解决了二十年，而且还在继续发展。
类似的，差分服务的框架也包含两个部分。一个是相当易于理解的在转发途中的处理举
措，另一个是十分复杂的、还是刚刚显现出来的用来配置在转发过程中所用参数的后台程序
与配置部件。其中，转发举措包括对于接受到的不同的包的区别对待，就如同在队列服务规
则与队列管理规则中实现的一样。这些“单段行为”是十分必要的，且不论我们怎样构建端
到端或整个域内的服务，需要网络中的节点能够转发我们区分对待了的包。我们的焦点在于
一般语义上的“行为”而非用来实现他们的特定机制。这是因为这些“行为”会比机制发展
的慢。
在每一个包的基础上选择它们的单段行为及其机制如今可以放置在网络节点中，这也是
差分服务所最先强调的问题。另外，转发所经的途径也需要训练、维护与整理来满足某些包
所需要的“特殊对待”。这种类型的流调控机制也是相当易于理解的。这种调控的广泛配置
在服务业务的构造中也是相当重要的，尽管它们的实际用途还要演化一段时间。
为使特定的包得到特定的对待而如何配置网络组成部分与使用何种规则来应用资源是
不大好理解的。尽管如此，用简单的策略与静态的配置在网络中展开差分服务还是可行的。
正如在[ARCH]中所描述的一般，构造单段行为与流边界调节器来创建不同服务的方法由许
多种。而且在此过程中，会得到许多经验来指导我们构建更复杂的策略与配置。当这一部件
演变发展之后，转发途中的基本行为仍是不变的。构造这些服务的经验会在相当一段时间内
继续发展下去，所以我们在这里尽量避免在这个构造成熟之前就把它标准化。进一步说，许
多服务构造的细节问题是与不同的商业实体之间的法定协议相关的，我们也避开这个问题因
为它不在IETF的研究范围内。
本文着重与转发途径上面的问题。在包转发的过程中，差分服务通过包含于IP包头的
一个字段的码值来映射一种特定的转发处理方式，即单段行为（PHB）,这是在转发途中的
每一节点中都要进行的。而这之中的码值，则可以从本文所定义的强制应用的值中选择，也
可从未来的文档所推荐的值中选择，或仅仅只是本地的自定义值。PHB的实现方法是：在
网络节点的输出接口处使用一系列队列服务或队列管理规则，如加权轮询(WRR)队列服务或
丢包优先级队列服务。
做标记的工作是由网络边界处的流调节器包括网络边缘节点（第一跳路由或源主机）与
有管理权限的边界点完成的。调节器的工作包括粗糙的打标记、测量与整理（这些机制在
[ARCH]中描述）。而整个服务的完成时通过利用在边界点上的特定包的分类与流调整机制再
加上在传送途中一连串的单段行为来表现的。差分服务的目的之一就是考虑将来的扩展性来
规定这些构造区块，包括区块的数量与种类，也包括从中构建的服务。
本文众说用道的术语在第二节中定义。差分业务字段的定义在第三节中给出。在第四届
中我们讨论它与IPv4优先级的向后兼容性。作为结论，我们介绍了类选择码值与类选择下
的PHB。第五章是单段行为标准化指南。第六章是定义码值的说明。第七章包含了一些有
关安全性的考虑。
本文只是简明的描述了DS字段及其使用。它应该参照“差分服务框架”（ARCH）阅读。
本文中用到的关键字“必须”、“不允许”、“需要”、“应该”、“不应该”、“可以”、“不可
以”、“建议”、“可能”、与“可选择”将在RFC2112中解释。
2. 本文所用术语

分组聚合：积聚通过某一通向某一特定方向的链路的具有相同码值的包。“聚合”与“分
组聚合”在本文中是等价交替使用的。
分类器：根据所定义的包头的内容选择包的一种实体。
类选择码值：在‘xxx000’（此处的‘x’可为‘0’或‘1’）之间的任意一个码值。我
们在4.2.2中讨论有关类选择码值的问题。
类选择对应的PHB：满足4.2.2.2中指定的类选择PHB条件的单段行为。
码值：DS字段中DS标记（DSCP）部分所指定的值。建议码值应该映射于特定的、标
准化的单段行为。多个码值可以对应同一PHB。
差分服务域边界：DS与的边缘。分类器与流定型器在此处配置。一个差分服务域边界
可一细化分为两种节点：入口节点与出口节点。它们分别对应在边缘链路的指定方向的上行
/下行流。典型的差分服务域边界位于包进入差分服务域的第一跳所对应的路由器（或网络
节点），或包离开差分服务域边界在到达目的之前所经过的最后一跳所对应的路由器（或网
络节点）。这种情况通常叫“叶路由器上的边界”，一个差分服务边界可以根据本地需要配置
在主机中。差分服务域边界也叫DS边界。
满足差分服务：与本文所指定的要求一致。
差分服务域：一系列协同满足差分服务策略管理的、连续的英特网的一部分。一个差分
服务于可以包括不同的主机与路由器、管理区域、自治域，不同的信任域与不同的网络技术
（比如信元或帧）等等。差分服务域也叫DS域。
差分服务字段：本文所给出定义的IP包头字段。实际上是IPv4中的TOS和IPv6中的
流标签八位组。也叫DS字段。
机制：特定算法所对应的一种或多种单段行为的实现方法。
微量流：应用程序到应用程序间的定义了源地址、目的地址、协议ID、源端口号、目
的端口号（当可用时）的流的一个实例。
单段行为（PHB）：有关DS节点对通过某一条链路的具有相同DSCP的分组集合所施
加的外部可见的转发行为的描述。PHB的描述应该足够详细，使之如[ARCH]中所描述的一
样可以构建可预见的服务。
PHB集合：一个或多个PHB组成的集合。这些PHB具有相同的指定意义，可以同时
完成，因为这些PHB具有相同的约束，比如队列服务或队列管理策略。
业务流定型：可用在分类聚合、应用业务流、或其他由意义的可操作的流的子集如路由
更新等方面的控制功能。这些功能可能包括计量、整形、丢弃、标记。业务流定型用来增强
域之间的协定，也可以通过在DS字段中作合适的标记与在必要时检查、改变某个聚合的临
时特性来在域中得到差分服务。详情请参看[ARCH]。
业务流定型器：一个具有业务流定型功能的实体。具体功能可以包括计量、整形、丢弃、
标记。业务流定型器一般配置于DS边界节点（也就是说，不在DS域的内部节点中）。
服务：对于客户的通过一特定的域、通过一系列互连的DS域或只是端对端的业务流的
全部的（或一个子集）的处理。服务的描述由管理机制所表现。服务的构造是通过应用业务
量定型来得到分组聚合（分组聚合在DS域中的每个节点都经历了特定的PHB）。多重服务
可以通过许多业务流定型器中所应用的同一单段行为来支持。
综上所述，分类器与业务流定型器起选择哪些包应该加入哪个分组聚合的作用。各个聚
合在DS域中由其差别而受到不同的服务，而业务流定型器可能会依照某些请求改变聚合的
短时特性。一个包的DS字段用来指定该报的分组聚合类别，从而达到决定这个包受到什么
样的转发处理。一个分组聚合分类器可以选择一种PHB方式（比如说，用差分输出对流服
务规则），这种选择基于包含在该DS域中所有网络节点中所定义的DS字段的码值。DS边
界的分类器于业务流定型器是按照特定的服务所设置的，而这种管理策略不在本文的讨论范
围之内。
与差分服务相关的一些附加定义在[ARCH]中给出。
3. DS字段的定义

我们定义DS字段来代表在[RFC791]中定义的IPv4包头中的TOS八位组与[IPv6]中所
定义的流标签八位组。
DS字段中的前六位定义为DS标记（码值），它用来在每个节点中选择包的PHB。剩下
的两位目前未定义的比特为CU字段。这个字段的定义与解释不在本文的讨论范围内。CU
位的值在差分服务节点对某一包进行单段行为时忽略。
DS字段的结构如下所示：
0    1    2    3    4    5    6    7
     +---+---+---+---+---+---+---+---+---+---+
|          DSCP           |   CU   |
     +---+---+---+---+---+---+---+---+---+---+

DSCP：差分服务码值，即DS标记值
CU：目前未定义

在本文所示的DS标记中，标记‘xxxxxx’（此处‘x’可为‘0’或‘1’）的最左端比特位
代表DS字段的0比特位，而其最右端比特代表DS字段的第5比特位。
业务的提供者要注意DS标记字段宽度是6比特。提供DS服务的节点必须严格的以这
6比特的DS标记字段来选择PHB。举例来说，用这个字段中定义的值作为一个索引表来选
定应该对一个特定的包作何种处理（当然这种处理机制已经在该节点中实现了）。CU字段
的值必须在选择PHB使被忽略（以便未来扩展功能）。，以便将来更加灵活的定义单端行为，
DS标记字段并未系统化定义。
由于以下所列出的问题，码值到PHB的映射必须是可以配置的。一个DS服务节点必
须支持可配置的由码值到PHB的映射表的逻辑等同性。PHB的定义必须包括所建议的默认
码值，这个码值必然是在对应的标准格式下（见第六节）独一无二的。就是说，服务必须在
其默认设置下支持本文建议的码值到PHB的映射。但相关操作可以对不同的码值用同一个
PHB，不论这个PHB是不是建议默认的。要注意的是，如果做出了这样的选择，就可能需
要在DS管理域边界对DS字段重新做标记，就算是边界两边所执行的PHB相同也是一样。
有关重新标记的深一步讨论请参考[ARCH]。
对于与一般设置不同的例外即码值为‘xxx000’的情况，我们将在4.2.2与4.3中讨论。
节点接到的包的码值若不能识别的话，节点应该把它当成作了默认标记的包而转发出去
（详见第四节），而且包的码值不能被改变。这类包不可以让网络节点产生故障。
上面所讲到的DS字段和现有的[RFC791]中的IPv4TOS八位组的定义是不同的。但正
如一个网段使用RFC791的指定优先级一样，我们可以假设DS域可以通过配置重新做标记
的边界节点来保护自己。正确的操作过程应当遵循[RFC791]，它指出：“如果这些指定优先
级只是在一特定网段中使用，那么这个网段就有责任控制接入与使用这些优先级。”在任何
情况下，DS边界确认DS字段的值都是明智的。因为一个上行流处的节点可以将这个值设
成任意数。这样，未做到独立与未正确配置边界节点的DS域可能会承担不可预见的服务。
为了提供所希望的本地的或端到端的服务，节点可能要重设DS字段的值。DS边界之间的
DS字段如何转换事关业务提供者与用户之间的业务性条约，不再本文的讨论范围之内。标
准的PHB使业务提供者可以从一系列众所周知的包转发策略中构建他们的服务。而这些策
略可能已经配置在用户的设备中了。
4. 从前的码值定义与PHB需求

正如本节将要讨论的一样，DS字段与现行协议的先后兼容性有一定的限制。我们强调
的“向后兼容性”有两个含义。首先，有一些单段行为已经广泛应用了（比方说，有一些满
足[RFC1812]所指定的IPv4优先级队列条件的行为），我们希望使他们在DS与节点中能够
得到不变得服务。另外，有一些现行码值满足IP优先级字段的描述，我们保留这些码值，
并将他们映射到满足一般需要（在4.2.2.2中详细说明）的PHB上，但注意这些码值对应的
特定的差分服务PHB可能有一些附加的说明。
注意，我们并未在维护与“DTR”或IPv4服务类型八位组“TOS”的向后兼容性方面
做过努力。
4.1默认PHB

DS服务节点中必须有一个默认的PHB。而这个PHB就是现行路由器中普遍的尽力转
发行为（见[RFC1812]）。但没有达到其他共识时，节点就应该假设该包是属于默认聚合的。
这种类型的包个能没有进行任何处理（没有要求服务）就发到网络中，网络应该尽可能多、
尽可能快的转发这类包，当然这是受到其他一些运用资源的策略限制的了。对这种PHB的
一种合理的实现方式为：当输出链路未被其他PHB要求所占用时，尽力法这个聚合中的包。
而构建服务的一个合理的策略应该是：不要让聚合空闲。这种情况下的一种实现机制可以是：
每个节点预留一小部分资源（比如说缓冲、带宽）来为默认聚合服务。这样就可以是根本不
知道差分服务的用户像今天一样使用尽力转发的网络了。而一个域引入差分服务所给它的消
费者与旁观者带来的对服务质量期望的冲击不在本文范围之内。默认PHB的建议码值的形
式为‘000000’；而‘000000’这个值必须映射到满足这些规范的PHB上。这个默认码值的
选择是与现行的[RFC791]兼容的。但节点发现一个包的码值没有映射到标准的或本地定义的
PHB上时，因该将它映射到默认PHB。
一个开始时做了默认行为标记的包在它进入另一个DS域的边界处可能会重新作另一个
标记，这样它在这个域中的转发会使用不同的PHB。这可能受制于域与域之间的合约。
4.2    曾经和将来的IP优先级字段

我们希望在差分业务中可以维护与现行IP优先级字段即IPv4TOS八位组的0-2比特位
的向后兼容性。现今的路由器在根据IP优先级字段选择不同的单段转发处理的操作与使用
我们所提议的DSCP字段是相同的。所以，适当的调整这些路由器就可以很快的构造出一个
简单的差分服务框架原型。另外，当今的IP系统知道IP优先级字段的位置，所以当我们配
置了用于DS服务的设备之后以相同的方式运用这个字段，不会在网络配置过程中出现重大
的错误。换句话说，就算在业务提供者的一个简单的网络中，若其DSCP字段的0-2比特与
其从前配置的IP优先级字段的配置方式相同或是包含于它的话，严格满足DS条件的设备
并不需要普遍存在。

4.2.1   IP优先级的历史与演变简述

从某种意义上说，IP优先级字段是DS字段的先驱，我们最初对IP优先级字段的定义
是在[RFC791]中。这个字段中的三个比特的值可能会指定起不同的作用，包括网络控制流、
路由信息流、或不同级别的优先级。其中的最低优先级是“路由信息流”。在[RFC791]中，
优先级的概念被广义的定义为“视数据流的重要程度而对其进行的独立处理”。并不是所有
的IP优先级字段的值在包通过边界节点时都被认为是有意义的，例如“网络控制的优先级
指定只会用在一个网段中，使用与管理这个指定权是网段自己的事”([RFC791])。
尽管早期的BBN IMPs（路由器）就实现了这种优先级特性，但早期的商用路由器与
UNIX IP转发机制不支持它。当网络越来越复杂、用户的要求越来越多时，上用路由器的卖
主们开始开发实现不同种类的排队服务的方法，包括优先级排队。优先级排队一般来说基于
路由器的过滤其中所编制的策略，它检查包的IP地址、IP端口号、TCP或UDP端口号与
其它字段。IP优先级字段就是过滤器可以检查的内容的一项。
总之，IP优先级已经广泛的配置与应用了，只不过它没有准确的按[RFC791]的方式进
行。[RFC1122]认识到了这个问题，它指出，设定IP优先级字段是正确的，但是[RFC791]
中明确指定的优先级已经成为历史。
4.2.2   包含IP优先级的类选择码值

根据IP优先级字段来规范一个包的转发策略在当今已经是十分普遍的了，但对于来构
建一个可预见服务质量的差分服务框架来说还不够完善。为了在不牺牲对于未来扩展的灵活
性的前提下保留对于现存IP优先级字段的部分兼容性，我们的方法是：用一系列PHB描述
最小的要求来与尽可能多的IP优先级字段配置的转发对策相对应。另外，我们给出了一系
列必须映射于满足这些最小要求的PHB的码值。注意，这些PHB可能在除了此处提到的条
件外还有一些详细的规范。剩余的码值可以映射的到这些PHB上。我们把这一系列码值叫
做类选择码值，而这些码值对应的PHB的最小需求叫类选择PHB条件。
4.2.2.1   类选择码值
由DS字段字为‘xxx000|xx’，或‘xxx000’加上未定义的CU自子段为保留类选择码
值。由这些码值所映射的PHB除保留‘000000’所对应的默认PHB需求外必须满足类选择
PHB条件（见4.1）。
4.2.2.2 类选择PHB条件

我们所说的类选择码值的数字越大，其相对的地位就越高；码值越小，其相对地位就越
低。八个类选择码所映射的一系列PHB至少要产生两类独立的流，而且在合理的操作情况
与业务负载下，一个类选择码值所规范的PHB应该给与对应包以不低于处于较低地位的类
选择码值所规范的、更及时的转发服务。丢包现象是不及时转发的极端情况。另外，码值
‘11x000’所选择的PHB必须要比码值‘000000’所选择的PHB优先，这是为了维护现行
的路由信息所对应的IP优先级值‘110’和‘111’的作用。
进一步说，明确的类选择码值选择的PHB应该被独立的转发，也就是说，作了不同的
类选择码值记号的包可能会被重新排序。一个网络节点可能会对每个PHB所需的节点资源
的量进行限制。
满足这些规范的PHB集就是满足类选择的PHB。
码值‘000000’的类选择PHB条件与4.1中所列出的默认PHB一致。
4.2.2.3   用类选择PHB条件与IP优先级兼容

一个DS服务节点中可以配置一系列的单个或多个类选择PHB集。本文已指出码自己
和‘xxx000’必须映射到这样的一系列PHB上。而由于多个码值可能映射到一个PHB，网
络的投资者或网络管理者可以在不考虑DSCP字段的3-5比特的情况下配置网络节点，这样
产生的网络必然与从前使用IP优先级的包兼容。比如说，码值‘011010’与码值‘011000’
在这种情况下受到的PHB是一样的。
4.2.2.4   实现满足类选择PHB集的机制举例

满足类选择PHB可通过多种机制实现，包括严格的优先级排队、加权公平排对（WFQ）、
WRR及其变种[RPS,HPFQA,DRR]、CBQ[CBQ]等等。这些机制及其对应PHB的区别将在第
五节中描述。
值得注意的是，这些机制可能会在某些的定卖主的设备中所可行的（标准或非标准的）
PHB中可行。举个例子来说，未来的文档可能会把严格优先级排队的PHB集定义在一组建
议码值上，而网络管理员会将这些路由器设置为选择码值‘xxx000’的包进行严格优先级排
队来满足该文档的要求。
再例如，某个卖主可能将CBQ机制做入了路由器，那么CBQ机制可能会被用来完成
严格优先级排队。这正如有很多特性的一系列类选择PHB在仅有最小的类选择PHB条件特
性下可行一样。
4.3   总结

本文定义了码值‘xxx000’来作为类选择码值，而由这些码值选择的PHB必须满足4.2.2.2
中描述的类选择PHB条件。这是为了保持当前所用的IP优先级字段的可用性的向后兼容性
且不影响未来的灵活性而指定的。另外，码值‘000000’用作默认PHB值而不准任意配置。
剩下的七个非零类选择码值可进行配置，但要满足4.2.2.2的要求。
5. 单段行为的标准化指南

此处要标准化的是PHB的操作特征，而不是具体的实现它们的特定算法与机制。一个
节点可能会有（相当大）一组参数来控制如何调度包，并将它们送到输出接口（比方说，N
个独立队列参数，队列长度，轮询加权值，丢包算法，丢包优先加权与门限等等）。为了说
明PHB与其机制的区别，我们应该看到类选择PHB可以为许多机制所实现，包括严格的优
先级排队、加权公平排对（WFQ）、WRR及其变种[RPS,HPFQA,DRR]、CBQ[CBQ]等等。
它们可以单独或混合使用。
PHB可以单独的设定，也可以作为集合而指定（单独的PHB是PHB集的特例）。PHB
集通常一个或多个PHB组成的集合。这些PHB具有相同的指定意义，可以同时完成，因为
这些PHB具有相同的约束，比如队列服务或队列管理策略。PHB集中有这样的情况：一个
包可能会为了在包中选择另一PHB而重新做了标记。在这里，建议完成PHB是不要对流中
包进行重新排序。还有，PHB集必须识别会发生在每个PHB上的包的重排序的任何可能，
以及在集合中一个微流中的不同的包做了不同的PHB标记的可能。
只有那些没有在现存PHB标准中描述过的、而被实现、配置且表明是有效的单段行为
是应该被标准化的。但是由于当今的差分服务的经验还十分有限，假定确切的单段行为的规
范是有欠成熟的。
任意一个标准化的PHB必须有一个对应的建议码值，这个码值是从32个值（见第六节）
中选择分配的。这一条给将来的演化发展流出了码值空间。这里定义的值（‘xxx000’）是有
意的定在了小范围内。
网络设备卖主可以提供它们认为有用的或由市场的任何参数和性能的设备。但一个节点
实现了特定的表准化PHB，买主可以在满足标准定义的PHB的情况下使用任意算法。节点
的性能与其特定设置决定了处理包的不同方法。
业务提供者不需要在其网络中使用不变的节点机制或配置来进行差分服务，他们可以任
意配置节点参数，只要它满足服务要求与业务工程目标即可。一段时间之后，某些通用的单
段行为可能要演变（即那些对实现端到端服务有其有效的操作），他们可能会与DS字段的
特定EXP/LU PHB码值有关，用来通过域边界（见第六节）。这些PHB有待未来的标准化。
建议参照[ARCH]来指定标准化PHB。
6. IANA考虑

DS字段中的DSCP字段可以有64个不同的码值。这个码值空间划分为三个部分（三个
池）：有32个建议码值的池一用作[CONS]中定义的标准操作，有16个码值的池二为[CONS]
中定义的实验与本地使用（EXP/LU）预留，剩下的有16个池三的值开始四是用作实验与本
地使用，但可能会在标准指定的池一耗尽后补充使用。这三个池的定义如下表（‘x’指‘0’
或‘1’）：
池              码值空间                  分配策略
    ----         ---------------           -----------------

1               xxxxx0                  标准操作
     2               xxxx11                  EXP/LU
     3               xxxx01                  EXP/LU (*)

（*）可能将来需要使用作标准操作

本文指定的八个建议码值（‘xxx000’），是从上面所说的池一中取的。这些码值必须被
映射，不是映射到特定的PHB，而是按先前4.2.2.2中所要求的最低要求来提供与[RFC791]
中定义的IP优先级（当今的一些设备所用）的最小限度的向后兼容性。
7. 安全性考虑

本节讨论由差分服务的引入所带来的安全性问题，主要问题在于拒绝访问攻击与未授权
的业务流的窃取服务的潜在可能性（7.1）。7.2节着重讲在IPsec的情况下差分服务的操作，
还有它与IPsec隧道模式和其他隧道模式协议的交互。有关差分服务整个结构的安全性问题
的广泛讨论请参阅[ARCH]。
7.1盗用与拒绝差分服务

差分服务的最初目标在于在相同的网络基础结构下，为业务流提供不同级别的服务。许
多技术都可以用来达到这一目标，即最终一些包将受到与其它包不同的（比如说更好的）服
务。将网络中的流映射于特定的转发行为将最终得到不同（好或坏）的服务，而这个服务从
根本上说是由DS码值所决定的。因此我们的对手可以通过改变码值，使码值代表增强服务，
或直接将有这种码值的包注入网络来得到更好的服务。作为这个问题的极端，当修改过的或
注入的流耗尽了用来转发它与其它业务流的资源时，这种盗用服务就成了拒绝服务攻击。对
于这种盗用与拒绝服务攻击的防范措施在于DS域边界的业务流整形与DS域网络基础构造
的安全性与整体性的结合。DS与边界节点必须保证所有进入域中的流所作的标记码值对本
地情况都是恰当的，且必要的话对流重新做标记。这些DS边界节点是防范基于码值修改的
盗用与拒绝服务攻击的第一道防线，因为这种攻击的成功表示攻击流所用的码值是不正确的
码值。需要指出的是边缘节点可以是DS域中任一流的源节点。DS域内的节点依靠DS码
字来确定流转发的PHB，不用再使用码值之前检查它。所以，内部节点可依赖DS域边界节
点的正确操作来防止得到不正确码值流或超出预备级别的服务而中断域的正常工作。
7.2   与IPsec和隧道技术的交互

在[ESP,AH]中定义的IPsec协议没有对IP包头的DS字段进行加密计算（在隧道模式中，
在外部的IP包头的DS字段未加密）。网络节点对DS字段的改变对于IPsec的端到端安全
性并没有任何影响，因为它不能使任何IPsec的校验失败。作为结论，IPsec并不提供任何
用来防范我们对手改变DS字段（换句话说，是中间人攻击）的方法，正如同我们对手对
DS字段的改变对IPsec的端到端安全性没作用一样。
IPsec的隧道模式对封装了的IP头中的DS字段提供安全保证。在隧道模式下的IPsec
包有两个包头：外部包头由隧道入口节点提供，而封装了的内部包头由包的源提供。但差封
服务网络（全部或部分）建立了IPsec隧道后，中间网络节点只能在外部包头的DS地段操
作了。在隧道的出口节点，IPsec的操作包括去掉外部包头与按包的内部包头转发（如果要
求这样的话）。IPsec协议要求内部包头的DS字段在解封装的过程中不改变，以次来保证在
IPsec隧道两端之间对DS字段的修改不会达到盗用与拒绝服务攻击的目的。本文对这一条
件没有变动。如果内部IP由于隧道出口节点在域内而未被DS边界节点处理的话，隧道的
出口节点就成为对于业务流出隧道的边界节点，因此必须确保得到的业务流有正确的DS码
值。
当在IPsec隧道出口的解封装过程中包含足够强度的对已封装的包的密码完整性的校验
（此处的强度是由本地安全策略决定的）时，隧道的出口节点可以安全的假设内部包头的
DS字段在与其到达隧道入口节点的值是相同。所以我们可以得到结论：DS域中的非安全链
路的安全性可以通过足够强度的IPsec隧道来保证。这一结论及其含义适用于任何进行完整
性校验的隧道协议技术，但内部包头DS字段的安全程度还有赖于隧道协议所进行的校验的
强度。在使用缺乏足够信任度的、可能经过当前DS域外的节点（或是易受攻击）的隧道的
情况下，封装了的包必须被当作是从DS域外来到了域边界来处理。

IP Header define

0                    1                    2                    3   
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|   IHL   |Type of Service|           Total Length          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Identification         |Flags|       Fragment Offset     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Time to Live |     Protocol    |          Header Checksum        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Source Address                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Destination Address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Options                     |     Padding     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(转贴)