As per Relevance of the word different, we have this rfc below:
Network Working Group K.
Request for Comments: 2474 Cisco
Obsoletes: 1455, 1349 S.
Category: Standards Track Torrent Networking
F.
Cisco
D.
EMC
December 1998
Definition of the Differentiated Services Field (DS Field
in the IPv4 and IPv6
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
Differentiated services enhancements to the Internet protocol
intended to enable scalable service discrimination in the
without the need for per-flow state and signaling at every hop.
variety of services may be built from a small, well-defined set
building blocks which are deployed in network nodes. The
may be either end-to-end or intra-domain; they include both
that can satisfy quantitative performance requirements (e.g.,
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
(autonomous system boundaries, internal administrative boundaries
or hosts),
- using those bits to determine how packets are forwarded by
nodes inside the network,
- conditioning the marked packets at network boundaries in
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
administrative policy mechanisms which are outside the scope of
document. A differentiated services-compliant network node
a classifier that selects packets based on the value of the DS field
along with buffer management and packet scheduling mechanisms
of delivering the specific packet forwarding treatment indicated
the DS field value. Setting of the DS field and conditioning of
temporal behavior of marked packets need only be performed at
boundaries and may vary in complexity
This document defines the IP header field, called the DS (
differentiated services) field. In IPv4, it defines the layout
the TOS octet; in IPv6, the Traffic Class octet. In addition, a
set of packet forwarding treatments, or per-hop behaviors,
defined
For a more complete understanding of differentiated services,
also the differentiated services architecture [ARCH].
Table of
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
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
4.2.2.4 Example Mechanisms for Implementing Class ......... 12
Selector Compliant PHB
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.
Differentiated services are intended to provide a framework
building blocks to enable deployment of scalable
discrimination in the Internet. The differentiated services
aims to speed deployment by separating the architecture into
major components, one of which is fairly well-understood and
other of which is just beginning to be understood. In this, we
guided by the original design of the Internet where the decision
made to separate the forwarding and routing components.
forwarding is the relatively simple task that needs to be
on a per-packet basis as quickly as possible. Forwarding uses
packet header to find an entry in a routing table that determines
packet's output interface. Routing sets the entries in that
and may need to reflect a range of transit and other policies as
as to keep track of route failures. Routing tables are maintained
a background process to the forwarding task. Further, routing is
more complex task and it has continued to evolve over the past 20
years
Analogously, the differentiated services architecture contains
main components. One is the fairly well-understood behavior in
forwarding path and the other is the more complex and still
background policy and allocation component that configures
used in the forwarding path. The forwarding path behaviors
the differential treatment an individual packet receives,
implemented by queue service disciplines and/or queue
disciplines. These per-hop behaviors are useful and required
network nodes to deliver differentiated treatment of packets
matter how we construct end-to-end or intra-domain services.
focus is on the general semantics of the behaviors rather than
specific mechanisms used to implement them since these behaviors
evolve less rapidly than the mechanisms
Per-hop behaviors and mechanisms to select them on a per-packet
can be deployed in network nodes today and it is this aspect of
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
"special" treatment in order to enforce requirements associated
the delivery of the special treatment. Mechanisms for this kind
traffic conditioning are also fairly well-understood. The
deployment of such traffic conditioners is also important to
the construction of services, though their actual use in
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
get special treatment and what kinds of rules are to be applied
the use of resources is much less well-understood. Nevertheless,
is possible to deploy useful differentiated services in networks
using simple policies and static configurations. As described
[ARCH], there are a number of ways to compose per-hop behaviors
traffic conditioners to create services. In the process,
experience is gained that will guide more complex policies
allocations. The basic behaviors in the forwarding path can
the same while this component of the architecture evolves
Experiences with the construction of such services will continue
some time, thus we avoid standardizing this construction as it
premature. Further, much of the details of service construction
covered by legal agreements between different business entities
we avoid this as it is very much outside the scope of the IETF
This document concentrates on the forwarding path component. In
packet forwarding path, differentiated services are realized
mapping the codepoint contained in a field in the IP packet header
a particular forwarding treatment, or per-hop behavior (PHB), at
network node along its path. The codepoints may be chosen from a
of mandatory values defined later in this document, from a set
recommended values to be defined in future documents, or may
purely local meaning. PHBs are expected to be implemented
employing a range of queue service and/or queue
disciplines on a network node's output interface queue: for
weighted round-robin (WRR) queue servicing or drop-preference
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
primitives of marking, metering, policing and shaping (
mechanisms are described in [ARCH]). Services are realized by
use of particular packet classification and traffic
mechanisms at boundaries coupled with the concatenation of per-
behaviors along the transit path of the traffic. A goal of
differentiated services architecture is to specify these
blocks for future extensibility, both of the number and type of
building blocks and of the services built from them
Terminology used in this memo is defined in Sec. 2.
differentiated services field definition (DS field) is given in Sec
3. In Sec. 4, we discuss the desire for partial
compatibility with current use of the IPv4 Precedence field. As
solution, we introduce Class Selector Codepoints and Class
Nichols, et. al. Standards Track [Page 4]
RFC 2474 Differentiated Services Field December 1998
Compliant PHBs. Sec. 5 presents guidelines for per-hop
standardization. Sec. 6 discusses guidelines for allocation
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
architecture [ARCH].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC2119].
2. Terminology Used in This
Behavior Aggregate: a collection of packets with the same
crossing a link in a particular direction. The terms "aggregate"
"behavior aggregate" are used interchangeably in this document
Classifier: an entity which selects packets based on the content
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
are discussed in Sec. 4.2.2.
Class Selector Compliant PHB: a per-hop behavior satisfying the
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,
classifiers and traffic conditioners are likely to be deployed.
differentiated services boundary can be further sub-divided
ingress and egress nodes, where the ingress/egress nodes are
downstream/upstream nodes of a boundary link in a given
direction. A differentiated services boundary typically is found
the ingress to the first-hop differentiated services-compliant
(or network node) that a host's packets traverse, or at the egress
the last-hop differentiated services-compliant router or network
that packets traverse before arriving at a host. This is
referred to as the boundary at a leaf router. A
services boundary may be co-located with a host, subject to
policy. Also DS boundary
Differentiated Services-Compliant: in compliance with
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
over which a consistent set of differentiated services policies
administered in a coordinated fashion. A differentiated
domain can represent different administrative domains or
systems, different trust regions, different network
(e.g., cell/frame), hosts and routers, etc. Also DS domain
Differentiated Services Field: the IPv4 header TOS octet or the IPv
Traffic Class octet when interpreted in conformance with
definition given in this document. Also DS field
Mechanism: The implementation of one or more per-hop
according to a particular algorithm
Microflow: a single instance of an application-to-application flow
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
forwarding treatment applied at a differentiated services-
node to a behavior aggregate. The description of a PHB SHOULD
sufficiently detailed to allow the construction of
services, as documented in [ARCH].
Per-hop Behavior Group: a set of one or more PHBs that can only
meaningfully specified and implemented simultaneously, due to
common constraint applying to all PHBs in the set such as a
servicing or queue management policy. Also PHB Group
Traffic Conditioning: control functions that can be applied to
behavior aggregate, application flow, or other operationally
subset of traffic, e.g., routing updates. These MAY
metering, policing, shaping, and packet marking.
conditioning is used to enforce agreements between domains and
condition traffic to receive a differentiated service within a
by marking packets with the appropriate codepoint in the DS field
by monitoring and altering the temporal characteristics of
aggregate where necessary. See [ARCH].
Traffic Conditioner: an entity that performs traffic
functions and which MAY contain meters, policers, shapers,
markers. Traffic conditioners are typically deployed in DS
nodes (i.e., not in interior nodes of a DS domain).
Service: a description of the overall treatment of (a subset of)
customer's traffic across a particular domain, across a set
interconnected DS domains, or end-to-end. Service descriptions
covered by administrative policy and services are constructed
Nichols, et. al. Standards Track [Page 6]
RFC 2474 Differentiated Services Field December 1998
applying traffic conditioning to create behavior aggregates
experience a known PHB at each node within the DS domain.
services can be supported by a single per-hop behavior used
concert with a range of traffic conditioners
To summarize, classifiers and traffic conditioners are used to
which packets are to be added to behavior aggregates.
receive differentiated treatment in a DS domain and
conditioners MAY alter the temporal characteristics of the
to conform to some requirements. A packet's DS field is used
designate the packet's behavior aggregate and is subsequently used
determine which forwarding treatment the packet receives. A
aggregate classifier which can select a PHB, for example
differential output queue servicing discipline, based on
codepoint in the DS field SHOULD be included in all network nodes
a DS domain. The classifiers and traffic conditioners at
boundaries are configured in accordance with some
specification, a matter of administrative policy outside the scope
this document
Additional differentiated services definitions are given in [ARCH].
3. Differentiated Services Field
A replacement header field, called the DS field, is defined, which
intended to supersede the existing definitions of the IPv4 TOS
[RFC791] and the IPv6 Traffic Class octet [IPv6].
Six bits of the DS field are used as a codepoint (DSCP) to select
PHB a packet experiences at each node. A two-bit currently
(CU) field is reserved and its definition and interpretation
outside the scope of this document. The value of the CU bits
ignored by differentiated services-compliant nodes when
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
CU: currently
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
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-
DSCP field, e.g., by treating the value of the field as a table
which is used to select a particular packet handling mechanism
has been implemented in that device. The value of the CU field
be ignored by PHB selection. The DSCP field is defined as
unstructured field to facilitate the definition of future per-
behaviors
With some exceptions noted below, the mapping of codepoints to
MUST be configurable. A DS-compliant node MUST support the
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-
mappings in their default configuration. Operators may choose to
different codepoints for a PHB, either in addition to or in place
the recommended default. Note that if operators do so choose, re
marking of DS fields may be necessary at administrative
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
as if they were marked for the Default behavior (see Sec. 4),
their codepoints should not be changed. Such packets MUST NOT
the network node to malfunction
The structure of the DS field shown above is incompatible with
existing definition of the IPv4 TOS octet in [RFC791].
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
[RFC791], which states: "If the actual use of these
designations is of concern to a particular network, it is
responsibility of that network to control the access to, and use of
those precedence designations." Validating the value of the DS
at DS boundaries is sensible in any case since an upstream node
easily set it to any arbitrary value. DS domains that are
isolated by suitably configured boundary nodes may
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
or end-to-end service. Specifications of DS field translations at
boundaries are the subject of service level agreements
providers and users, and are outside the scope of this document
Standardized PHBs allow providers to build their services from
well-known set of packet forwarding treatments that can be
to be present in the equipment of many vendors
4. Historical Codepoint Definitions and PHB
The DS field will have a limited backwards compatibility with
practice, as described in this section. Backwards compatibility
addressed in two ways. First, there are per-hop behaviors that
already in widespread use (e.g., those satisfying the IPv4
queueing requirements specified in [RFC1812]), and we wish to
their continued use in DS-compliant nodes. In addition, there
some codepoints that correspond to historical use of the
Precedence field and we reserve these codepoints to map to PHBs
meet the general requirements specified in Sec. 4.2.2.2, though
specific differentiated services PHBs mapped to by those
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
A "default" PHB MUST be available in a DS-compliant node. This
the common, best-effort forwarding behavior available in
routers as standardized in [RFC1812]. When no other agreements
in place, it is assumed that packets belong to this aggregate.
packets MAY be sent into a network without adhering to any
rules and the network will deliver as many of these packets
possible and as soon as possible, subject to other resource
constraints. A reasonable implementation of this PHB would be
queueing discipline that sends packets of this aggregate whenever
output link is not required to satisfy another PHB. A
policy for constructing services would ensure that the aggregate
not "starved". This could be enforced by a mechanism in each
that reserves some minimal resources (e.g, buffers, bandwidth)
Default behavior aggregates. This permits senders that are
differentiated services-aware to continue to use the network in
same manner as today. The impact of the introduction
differentiated services into a domain on the service expectations
its customers and peers is a complex matter involving
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
Nichols, et. al. Standards Track [Page 9]
RFC 2474 Differentiated Services Field December 1998
specifications. The codepoint chosen for Default behavior
compatible with existing practice [RFC791]. Where a codepoint is
mapped to a standardized or local use PHB, it SHOULD be mapped to
Default PHB
A packet initially marked for the Default behavior MAY be re-
with another codepoint as it passes a boundary into a DS domain
that it will be forwarded using a different PHB within that domain
possibly subject to some negotiated agreement between the
domains
4.2 Once and Future IP Precedence Field
We wish to maintain some form of backward compatibility with
uses of the IP Precedence Field: bits 0-2 of the IPv4 TOS octet
Routers exist that use the IP Precedence field to select
per-hop forwarding treatments in a similar way to the use
here for the DSCP field. Thus, a simple prototype
services architecture can be quickly deployed by
configuring these routers. Further, IP systems today understand
location of the IP Precedence field, and thus if these bits are
in a similar manner as DS-compliant equipment is deployed
significant failures are not likely during early deployment.
other words, strict DS-compliance need not be ubiquitous even
a single service provider's network if bits 0-2 of the DSCP field
employed in a manner similar to, or subsuming, the deployed uses
the IP Precedence field
4.2.1 IP Precedence History and Evolution in
The IP Precedence field is something of a forerunner of the DS field
IP Precedence, and the IP Precedence Field, were first defined
[RFC791]. The values that the three-bit IP Precedence Field
take were assigned to various uses, including network
traffic, routing traffic, and various levels of privilege. The
level of privilege was deemed "routine traffic". In [RFC791],
notion of Precedence was defined broadly as "An independent
of the importance of this datagram." Not all values of the
Precedence field were assumed to have meaning across boundaries,
instance "The Network Control precedence designation is intended
be used within a network only. The actual use and control of
designation is up to each network." [RFC791]
Although early BBN IMPs implemented the Precedence feature,
commercial routers and UNIX IP forwarding code generally did not.
networks became more complex and customer requirements grew
commercial router vendors developed ways to implement various
of queueing services including priority queueing, which
Nichols, et. al. Standards Track [Page 10]
RFC 2474 Differentiated Services Field December 1998
generally based on policies encoded in filters in the routers,
examined IP addresses, IP protocol numbers, TCP or UDP ports,
other header fields. IP Precedence was and is among the options
filters can examine
In short, IP Precedence is widely deployed and widely used, if not
exactly the manner intended in [RFC791]. This was recognized
[RFC1122], which states that while the use of the IP Precedence
is valid, the specific assignment of the priorities in [RFC791]
merely historical
4.2.2 Subsuming IP Precedence into Class Selector
A specification of the packet forwarding treatments selected by
IP Precedence field today would have to be quite general;
not specific enough to build predictable services from in
differentiated services framework. To preserve partial
compatibility with known current uses of the IP Precedence
without sacrificing future flexibility, we have taken the approach
describing minimum requirements on a set of PHBs that are
with most of the deployed forwarding treatments selected by the
Precedence field. In addition, we give a set of codepoints that
map to PHBs meeting these minimum requirements. The PHBs mapped
by these codepoints MAY have a more detailed list of
in addition to the required ones stated here. Other codepoints
map to these same PHBs. We refer to this set of codepoints as
Class Selector Codepoints, and the minimum requirements for PHBs
these codepoints may map to are called the Class Selector
Requirements
4.2.2.1 The Class Selector
A specification of the packet forwarding treatments selected by
The DS field values of 'xxx000|xx', or DSCP = 'xxx000' and
subfield unspecified, are reserved as a set of Class
Codepoints. PHBs which are mapped to by these codepoints
satisfy the Class Selector PHB requirements in addition to
the Default PHB requirement on codepoint '000000' (Sec. 4.1).
4.2.2.2 The Class Selector PHB
We refer to a Class Selector Codepoint with a larger numerical
than another Class Selector Codepoint as having a higher
order while a Class Selector Codepoint with a smaller numerical
than another Class Selector Codepoint is said to have a
relative order. The set of PHBs mapped to by the eight
Selector Codepoints MUST yield at least two independently
classes of traffic, and PHBs selected by a Class Selector
Nichols, et. al. Standards Track [Page 11]
RFC 2474 Differentiated Services Field December 1998
SHOULD give packets a probability of timely forwarding that is
lower than that given to packets marked with a Class
codepoint of lower relative order, under reasonable
conditions and traffic loads. A discarded packet is considered to
an extreme case of untimely forwarding. In addition, PHBs
by codepoints '11x000' MUST give packets a preferential
treatment by comparison to the PHB selected by codepoint '000000'
preserve the common usage of IP Precedence values '110' and '111'
routing traffic
Further, PHBs selected by distinct Class Selector Codepoints
be independently forwarded; that is, packets marked with
Class Selector Codepoints MAY be re-ordered. A network node
enforce limits on the amount of the node's resources that can
utilized by each of these PHBs
PHB groups whose specification satisfy these requirements
referred to as Class Selector Compliant PHBs
The Class Selector PHB Requirements on codepoint '000000'
compatible with those listed for the Default PHB in Sec. 4.1.
4.2.2.3 Using the Class Selector PHB Requirements for IP
A DS-compliant network node can be deployed with a set of one or
Class Selector Compliant PHB groups. This document states that
set of codepoints 'xxx000' MUST map to such a set of PHBs. As it
also possible to map multiple codepoints to the same PHB, the
or the network administrator MAY configure the network node to
codepoints to PHBs irrespective of bits 3-5 of the DSCP field
yield a network that is compatible with historical IP Precedence use
Thus, for example, codepoint '011010' would map to the same PHB
codepoint '011000'.
4.2.2.4 Example Mechanisms for Implementing Class Selector
PHB
Class Selector Compliant PHBs can be realized by a variety
mechanisms, including strict priority queueing, weighted
queueing (WFQ), WRR, or variants [RPS, HPFQA, DRR], or Class-
Queuing [CBQ]. The distinction between PHBs and mechanisms
described in more detail in Sec. 5.
It is important to note that these mechanisms might be
through other PHBs (standardized or not) that are available in
particular vendor's equipment. For example, future documents
standardize a Strict Priority Queueing PHB group for a set
Nichols, et. al. Standards Track [Page 12]
RFC 2474 Differentiated Services Field December 1998
recommended codepoints. A network administrator might
those routers to select the Strict Priority Queueing PHBs
codepoints 'xxx000' in conformance with the requirements of
document
As a further example, another vendor might employ a CBQ mechanism
its routers. The CBQ mechanism could be used to implement the
Priority Queueing PHBs as well as a set of Class Selector
PHBs with a wider range of features than would be available in a
of PHBs that did no more than meet the minimum Class Selector
requirements
4.3
This document defines codepoints 'xxx000' as the Class
codepoints, where PHBs selected by these codepoints MUST meet
Class Selector PHB Requirements described in Sec. 4.2.2.2. This
done to preserve a useful level of backward compatibility
current uses of the IP Precedence field in the Internet
unduly limiting future flexibility. In addition, codepoint '000000'
is used as the Default PHB value for the Internet and, as such,
not configurable. The remaining seven non-zero Class
codepoints are configurable only to the extent that they map to
that meet the requirements in Sec. 4.2.2.2.
5. Per-Hop Behavior Standardization
The behavioral characteristics of a PHB are to be standardized,
not the particular algorithms or the mechanisms used to
them. A node may have a (possibly large) set of parameters that
be used to control how packets are scheduled onto an output
(e.g., N separate queues with settable priorities, queue lengths
round-robin weights, drop algorithm, drop preference weights
thresholds, etc). To illustrate the distinction between a PHB and
mechanism, we point out that Class Selector Compliant PHBs might
implemented by several mechanisms, including: strict
queueing, WFQ, WRR, or variants [HPFQA, RPS, DRR], or CBQ [CBQ],
isolation or in combination
PHBs may be specified individually, or as a group (a single PHB is
special case of a PHB group). A PHB group usually consists of a
of two or more PHBs that can only be meaningfully specified
implemented simultaneously, due to a common constraint applying
each PHB within the group, such as a queue servicing or
management policy. A PHB group specification SHOULD
conditions under which a packet might be re-marked to select
PHB within the group. It is RECOMMENDED that PHB implementations
not introduce any packet re-ordering within a microflow. PHB
Nichols, et. al. Standards Track [Page 13]
RFC 2474 Differentiated Services Field December 1998
specifications MUST identify any possible packet re-
implications which may occur for each individual PHB, and which
occur if different packets within a microflow are marked
different PHBs within the group
Only those per-hop behaviors that are not described by an
PHB standard, and have been implemented, deployed, and shown to
useful, SHOULD be standardized. Since current experience
differentiated services is quite limited, it is premature
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).
specification has left room in the codepoint space to allow
evolution, thus the defined space ('xxx000') is intentionally sparse
Network equipment vendors are free to offer whatever parameters
capabilities are deemed useful or marketable. When a particular
standardized PHB is implemented in a node, a vendor MAY use
algorithm that satisfies the definition of the PHB according to
standard. The node's capabilities and its particular
determine the different ways that packets can be treated
Service providers are not required to use the same node mechanisms
configurations to enable service differentiation within
networks, and are free to configure the node parameters in
way that is appropriate for their service offerings and
engineering objectives. Over time certain common per-hop
are likely to evolve (i.e., ones that are particularly useful
implementing end-to-end services) and these MAY be associated
particular EXP/LU PHB codepoints in the DS field, allowing use
domain boundaries (see Sec. 6). These PHBs are candidates for
standardization
It is RECOMMENDED that standardized PHBs be specified in
with the guidelines set out in [ARCH].
6. IANA
The DSCP field within the DS field is capable of conveying 64
distinct codepoints. The codepoint space is divided into three
for the purpose of codepoint assignment and management: a pool of 32
RECOMMENDED codepoints (Pool 1) to be assigned by Standards Action
defined in [CONS], a pool of 16 codepoints (Pool 2) to be
for experimental or Local Use (EXP/LU) as defined in [CONS], and
pool of 16 codepoints (Pool 3) which are initially available
experimental or local use, but which should be
Nichols, et. al. Standards Track [Page 14]
RFC 2474 Differentiated Services Field December 1998
utilized for standardized assignments if Pool 1 is ever exhausted
The pools are defined in the following table (where 'x' refers
either '0' or '1'):
Pool Codepoint space Assignment
---- --------------- -----------------
1 xxxxx0 Standards
2 xxxx11 EXP/
3 xxxx01 EXP/LU (*)
(*) may be utilized for future Standards Action allocations
This document assigns eight RECOMMENDED codepoints ('xxx000')
are drawn from Pool 1 above. These codepoints MUST be mapped, not
specific PHBs, but to PHBs that meet "at least" the requirements
forth in Sec. 4.2.2.2 to provide a minimal level of
compatibility with IP Precedence as defined in [RFC791] and
deployed in some current equipment
7. Security
This section considers security issues raised by the introduction
differentiated services, primarily the potential for denial-of
service attacks, and the related potential for theft of service
unauthorized traffic (Section 7.1). Section 7.2 addresses
operation of differentiated services in the presence of
including its interaction with IPsec tunnel mode and other
protocols. See [ARCH] for more extensive treatment of the
concerns raised by the overall differentiated services architecture
7.1 Theft and Denial of
The primary goal of differentiated services is to allow
levels of service to be provided for traffic streams on a
network infrastructure. A variety of techniques may be used
achieve this, but the end result will be that some packets
different (e.g., better) service than others. The mapping of
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
modifying the codepoint to values indicating behaviors used
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
resources available to forward it and other traffic streams
Nichols, et. al. Standards Track [Page 15]
RFC 2474 Differentiated Services Field December 1998
The defense against this class of theft- and denial-of-
attacks consists of the combination of traffic conditioning at
domain boundaries with security and integrity of the
infrastructure within a DS domain. DS domain boundary nodes
ensure that all traffic entering the domain is marked with
values appropriate to the traffic and the domain, remarking
traffic with new codepoint values if necessary. These DS
nodes are the primary line of defense against theft- and denial-of
service attacks based on modified codepoints, as success of any
attack indicates that the codepoints used by the attacking
were inappropriate. An important instance of a boundary node is
any traffic-originating node within a DS domain is the
boundary node for that traffic. Interior nodes in a DS domain
on DS codepoints to associate traffic with the forwarding PHBs,
are NOT REQUIRED to check codepoint values before using them. As
result, the interior nodes depend on the correct operation of the
domain boundary nodes to prevent the arrival of traffic
inappropriate codepoints or in excess of provisioned levels
would disrupt operation of the domain
7.2 IPsec and Tunnelling
The IPsec protocol, as defined in [ESP, AH], does not include the
header's DS field in any of its cryptographic calculations (in
case of tunnel mode, it is the outer IP header's DS field that is
included). Hence modification of the DS field by a network node
no effect on IPsec's end-to-end security, because it cannot cause
IPsec integrity check to fail. As a consequence, IPsec does
provide any defense against an adversary's modification of the
field (i.e., a man-in-the-middle attack), as the adversary'
modification will also have no effect on IPsec's end-to-end security
IPsec's tunnel mode provides security for the encapsulated
header's DS field. A tunnel mode IPsec packet contains two
headers: an outer header supplied by the tunnel ingress node and
encapsulated inner header supplied by the original source of
packet. When an IPsec tunnel is hosted (in whole or in part) on
differentiated services network, the intermediate network
operate on the DS field in the outer header. At the tunnel
node, IPsec processing includes removing the outer header
forwarding the packet (if required) using the inner header.
IPsec protocol REQUIRES that the inner header's DS field not
changed by this decapsulation processing to ensure that
to the DS field cannot be used to launch theft- or denial-of-
attacks across an IPsec tunnel endpoint. This document makes
change to that requirement. If the inner IP header has not
processed by a DS boundary node for the tunnel egress node's
Nichols, et. al. Standards Track [Page 16]
RFC 2474 Differentiated Services Field December 1998
domain, the tunnel egress node is the boundary node for
exiting the tunnel, and hence MUST ensure that the resulting
has appropriate DS codepoints
When IPsec tunnel egress decapsulation processing includes
sufficiently strong cryptographic integrity check of the
packet (where sufficiency is determined by local security policy),
the tunnel egress node can safely assume that the DS field in
inner header has the same value as it had at the tunnel ingress node
An important consequence is that otherwise insecure links within a
domain can be secured by a sufficiently strong IPsec tunnel.
analysis and its implications apply to any tunnelling protocol
performs integrity checks, but the level of assurance of the
header's DS field depends on the strength of the integrity
performed by the tunnelling protocol. In the absence of
assurance for a tunnel that may transit nodes outside the current
domain (or is otherwise vulnerable), the encapsulated packet MUST
treated as if it had arrived at a boundary from outside the
domain
8.
The authors would like to acknowledge the Differentiated
Working Group for discussions which helped shape this document
9.
[AH] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z
and W. Weiss, "An Architecture for
Services", RFC 2475, December 1998.
[CBQ] S. Floyd and V. Jacobson, "Link-sharing and
Management Models for Packet Networks", IEEE/
Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
August 1995.
[CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", RFC 2434,
1998.
[DRR] M. Shreedhar and G. Varghese, Efficient Fair
using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995.
Nichols, et. al. Standards Track [Page 17]
RFC 2474 Differentiated Services Field December 1998
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating
Payload (ESP)", RFC 2406, November 1998.
[HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet
Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC1122] Braden, R., "Requirements for Internet hosts -
communication layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., Editor, "Requirements for IP Version 4
Routers", RFC 1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RPS] D. Stiliadis and A. Varma, "Rate-Proportional Servers:
Design Methodology for Fair Queueing Algorithms", IEEE
ACM Trans. on Networking, April 1998.
Nichols, et. al. Standards Track [Page 18]
RFC 2474 Differentiated Services Field December 1998
Authors'
Kathleen
Cisco
170 West Tasman
San Jose, CA 95134-1706
Phone: +1-408-525-4857
EMail: kmn@cisco.
Steven
Torrent Networking
3000 Aerial Center, Suite 140
Morrisville, NC 27560
Phone: +1-919-468-8466 x232
EMail: slblake@torrentnet.
Fred
Cisco
519 Lado
Santa Barbara, CA 93111
Phone: +1-408-526-4257
EMail: fred@cisco.
David L.
EMC
35 Parkwood
Hopkinton, MA 01748
Phone: +1-508-435-1000 x76140
EMail: black_david@emc.
Nichols, et. al. Standards Track [Page 19]
RFC 2474 Differentiated Services Field December 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Nichols, et. al. Standards Track [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
