< draft-ietf-diffserv-header-02.txt   draft-ietf-diffserv-header-03.txt >
INTERNET-DRAFT Kathleen Nichols INTERNET-DRAFT Kathleen Nichols
Diffserv Working Group Bay Networks Diffserv Working Group Cisco Systems
Expires: February 1999 Steven Blake Expires: April 1999 Steven Blake
Torrent Networking Technologies Torrent Networking Technologies
Fred Baker Fred Baker
Cisco Systems Cisco Systems
David L. Black David L. Black
The Open Group EMC Corporation
August 1998 October 1998
Definition of the Differentiated Services Field (DS Field) Definition of the Differentiated Services Field (DS Field)
in the IPv4 and IPv6 Headers in the IPv4 and IPv6 Headers
<draft-ietf-diffserv-header-02.txt> <draft-ietf-diffserv-header-03.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 10, line ? skipping to change at page 10, line ?
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract Abstract
Differentiated services enhancements to the IP protocol are intended Differentiated services enhancements to the Internet protocol are
to enable scalable service discrimination in the Internet without the intended to enable scalable service discrimination in the Internet
need for per-flow state and signaling at every hop. A variety of without the need for per-flow state and signaling at every hop. A
services may be built from a small, well-defined set of building variety of services may be built from a small, well-defined set of
blocks which are deployed in network nodes. The services may be building blocks which are deployed in network nodes. The services
either end-to-end or intra-domain; they include both those that can may be either end-to-end or intra-domain; they include both those
satisfy quantitative performance requirements (e.g., peak bandwidth) that can satisfy quantitative performance requirements (e.g., peak
and those based on relative performance (e.g., "class" bandwidth) and those based on relative performance (e.g., "class"
differentiation). Services can be constructed by a combination of: differentiation). Services can be constructed by a combination of:
- setting bits in an IP header field at network boundaries - setting bits in an IP header field at network boundaries
(autonomous system boundaries, internal administrative boundaries, (autonomous system boundaries, internal administrative boundaries,
Nichols, et. al. Expires: February 1999 [Page 1] Nichols, et. al. Expires: April 1999 [Page 1]
or hosts), or hosts),
- using those bits to determine how packets are forwarded by the - using those bits to determine how packets are forwarded by the
nodes inside the network, and nodes inside the network, and
- conditioning the marked packets at network boundaries in accordance - conditioning the marked packets at network boundaries in accordance
with the requirements or rules of each service. with the requirements or rules of each service.
The requirements or rules of each service must be set through The requirements or rules of each service must be set through
administrative policy mechanisms which are outside the scope of this administrative policy mechanisms which are outside the scope of this
document. A differentiated services-compliant network node includes a document. A differentiated services-compliant network node includes
classifier that selects packets based on the value of the DS field a classifier that selects packets based on the value of the DS field
and is capable of delivering the specific packet forwarding treatment and is capable of delivering the specific packet forwarding treatment
indicated by the DS field value. Setting of the DS field and indicated by the DS field value. Setting of the DS field and
conditioning of the temporal behavior of marked packets need only be conditioning of the temporal behavior of marked packets need only be
performed at network boundaries and may vary in complexity. performed at network boundaries and may vary in complexity.
This document defines the IP header field, called the DS (for This document defines the IP header field, called the DS (for
differentiated services) field. In IPv4, it defines the layout of differentiated services) field. In IPv4, it defines the layout of
the TOS octet; in IPv6, the Traffic Class octet. In addition, a base the TOS octet; in IPv6, the Traffic Class octet. In addition, a base
set of packet forwarding treatments, or per-hop behaviors, is set of packet forwarding treatments, or per-hop behaviors, is
defined. defined.
skipping to change at page 10, line ? skipping to change at page 10, line ?
4.2.2 Subsuming IP Precedence into Class Selector .......... 10 4.2.2 Subsuming IP Precedence into Class Selector .......... 10
Codepoints Codepoints
4.2.2.1 The Class Selector Codepoints ..................... 11 4.2.2.1 The Class Selector Codepoints ..................... 11
4.2.2.2 The Class Selector PHB Requirements ............... 11 4.2.2.2 The Class Selector PHB Requirements ............... 11
4.2.2.3 Using the Class Selector PHB Requirements ......... 11 4.2.2.3 Using the Class Selector PHB Requirements ......... 11
for IP Precedence Compatibility for IP Precedence Compatibility
4.2.2.4 Example Mechanisms for Implementing Class ......... 12 4.2.2.4 Example Mechanisms for Implementing Class ......... 12
Selector Compliant PHB Groups Selector Compliant PHB Groups
4.3 Summary ................................................... 12 4.3 Summary ................................................... 12
5. Per-Hop Behavior Standardization Guidelines .................. 12 5. Per-Hop Behavior Standardization Guidelines .................. 12
6. IANA Considerations .......................................... 14 6. IANA Considerations .......................................... 13
7. Security Considerations ...................................... 14 7. Security Considerations ...................................... 14
7.1 Theft and Denial of Service ............................... 14 7.1 Theft and Denial of Service ............................... 14
7.2 IPsec and Tunneling Interactions .......................... 15 7.2 IPsec and Tunneling Interactions .......................... 15
8. Acknowledgments .............................................. 16 8. Acknowledgments .............................................. 16
9. References ................................................... 16 9. References ................................................... 16
Appendix A. Examples of Class Selector Compliant PHB ............ 17 Authors' Addresses ............................................... 17
Implementations Full Copyright Statement ......................................... 18
A.1 Priority Queues ........................................... 17
Nichols, et. al. Expires: February 1999 [Page 2]
A.2 Round Robin Queueing ...................................... 18
A.3 Virtual Circuit or Virtual Channel Selection .............. 18
A.4 Priority Buffer Management ................................ 19
Authors' Addresses ............................................... 19
Full Copyright Statement ......................................... 20
Nichols, et. al. Expires: April 1999 [Page 2]
1. Introduction 1. Introduction
Differentiated services are intended to provide a framework and Differentiated services are intended to provide a framework and
building blocks to enable deployment of scalable service building blocks to enable deployment of scalable service
discrimination in the Internet. The differentiated services approach discrimination in the Internet. The differentiated services approach
aims to speed deployment by separating the architecture into two aims to speed deployment by separating the architecture into two
major components, one of which is fairly well-understood and the major components, one of which is fairly well-understood and the
other of which is just beginning to be understood. In this, we are 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 guided by the original design of the Internet where the decision was
made to separate the forwarding and routing components. Packet made to separate the forwarding and routing components. Packet
skipping to change at page 10, line ? skipping to change at page 10, line ?
differentiated services architecture that is being addressed first. differentiated services architecture that is being addressed first.
In addition, the forwarding path may require that some monitoring, In addition, the forwarding path may require that some monitoring,
policing, and shaping be done on the network traffic designated for policing, and shaping be done on the network traffic designated for
"special" treatment in order to enforce requirements associated with "special" treatment in order to enforce requirements associated with
the delivery of the special treatment. Mechanisms for this kind of the delivery of the special treatment. Mechanisms for this kind of
traffic conditioning are also fairly well-understood. The wide traffic conditioning are also fairly well-understood. The wide
deployment of such traffic conditioners is also important to enable deployment of such traffic conditioners is also important to enable
the construction of services, though their actual use in constructing the construction of services, though their actual use in constructing
services may evolve over time. services may evolve over time.
Nichols, et. al. Expires: February 1999 [Page 3]
The configuration of network elements with respect to which packets The configuration of network elements with respect to which packets
get special treatment and what kinds of rules are to be applied to get special treatment and what kinds of rules are to be applied to
the use of resources is much less well-understood. Nevertheless, the use of resources is much less well-understood. Nevertheless,
it is possible to deploy useful differentiated services in networks it is possible to deploy useful differentiated services in networks
by using simple policies and static configurations. As described in by using simple policies and static configurations. As described in
[ARCH], there are a number of ways to compose per-hop behaviors and [ARCH], there are a number of ways to compose per-hop behaviors and
Nichols, et. al. Expires: April 1999 [Page 3]
traffic conditioners to create services. In the process, additional traffic conditioners to create services. In the process, additional
experience is gained that will guide more complex policies and experience is gained that will guide more complex policies and
allocations. The basic behaviors in the forwarding path can remain allocations. The basic behaviors in the forwarding path can remain
the same while this component of the architecture evolves. the same while this component of the architecture evolves.
Experiences with the construction of such services will continue for Experiences with the construction of such services will continue for
some time, thus we avoid standardizing this construction as it is some time, thus we avoid standardizing this construction as it is
premature. Further, much of the details of service construction are premature. Further, much of the details of service construction are
covered by legal agreements between different business entities and covered by legal agreements between different business entities and
we avoid this as it is very much outside the scope of the IETF. we avoid this as it is very much outside the scope of the IETF.
skipping to change at page 10, line ? skipping to change at page 10, line ?
blocks for future extensibility, both of the number and type of the blocks for future extensibility, both of the number and type of the
building blocks and of the services built from them. building blocks and of the services built from them.
Terminology used in this draft is defined in Sec. 2. The Terminology used in this draft is defined in Sec. 2. The
differentiated services field definition (DS field) is given in Sec. differentiated services field definition (DS field) is given in Sec.
3. In Sec. 4, we discuss the desire for partial backwards 3. In Sec. 4, we discuss the desire for partial backwards
compatibility with current use of the IPv4 Precedence field. As a compatibility with current use of the IPv4 Precedence field. As a
solution, we introduce Class Selector Codepoints and Class Selector solution, we introduce Class Selector Codepoints and Class Selector
Compliant PHBs. Sec. 5 presents guidelines for per-hop behavior Compliant PHBs. Sec. 5 presents guidelines for per-hop behavior
standardization. Sec. 6 discusses guidelines for allocation of standardization. Sec. 6 discusses guidelines for allocation of
codepoints. Sec. 7 covers security considerations. We present codepoints. Sec. 7 covers security considerations.
examples of Class Selector Compliant PHB implementations in the
Appendix.
Nichols, et. al. Expires: February 1999 [Page 4]
This document is a concise description of the DS field and its uses. This document is a concise description of the DS field and its uses.
It is intended to be read along with the differentiated services It is intended to be read along with the differentiated services
architecture [ARCH]. architecture [ARCH].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Nichols, et. al. Expires: April 1999 [Page 4]
2. Terminology Used in This Document 2. Terminology Used in This Document
Behavior Aggregate: a collection of packets with the same codepoint Behavior Aggregate: a collection of packets with the same codepoint
crossing a link in a particular direction. The terms "aggregate" and crossing a link in a particular direction. The terms "aggregate" and
"behavior aggregate" are used interchangeably in this document. "behavior aggregate" are used interchangeably in this document.
Classifier: an entity which selects packets based on the content of Classifier: an entity which selects packets based on the content of
packet headers according to defined rules. packet headers according to defined rules.
Class Selector Codepoint: any of the eight codepoints in the range Class Selector Codepoint: any of the eight codepoints in the range
skipping to change at page 10, line ? skipping to change at page 10, line ?
Recommended codepoints SHOULD map to specific, standardized PHBs. Recommended codepoints SHOULD map to specific, standardized PHBs.
Multiple codepoints MAY map to the same PHB. Multiple codepoints MAY map to the same PHB.
Differentiated Services Boundary: the edge of a DS domain, where Differentiated Services Boundary: the edge of a DS domain, where
classifiers and traffic conditioners are likely to be deployed. A classifiers and traffic conditioners are likely to be deployed. A
differentiated services boundary can be further sub-divided into differentiated services boundary can be further sub-divided into
ingress and egress nodes, where the ingress/egress nodes are the ingress and egress nodes, where the ingress/egress nodes are the
downstream/upstream nodes of a boundary link in a given traffic downstream/upstream nodes of a boundary link in a given traffic
direction. A differentiated services boundary typically is found at direction. A differentiated services boundary typically is found at
the ingress to the first-hop differentiated services-compliant router the ingress to the first-hop differentiated services-compliant router
(or network node) a host's packets traverse, or at the egress of the (or network node) that a host's packets traverse, or at the egress of
last-hop differentiated services-compliant router or network node the last-hop differentiated services-compliant router or network node
packets traverse before arriving at a host. This is sometimes that packets traverse before arriving at a host. This is sometimes
referred to as the boundary at a leaf router. A differentiated referred to as the boundary at a leaf router. A differentiated
services boundary might be co-located with a host, subject to local services boundary may be co-located with a host, subject to local
policy. Also DS boundary. policy. Also DS boundary.
Differentiated Services-Compliant: in compliance with the Differentiated Services-Compliant: in compliance with the
requirements specified in this document. requirements specified in this document. Also DS-compliant.
Differentiated Services Domain: a contiguous portion of the Internet Differentiated Services Domain: a contiguous portion of the Internet
over which a consistent set of differentiated services policies are over which a consistent set of differentiated services policies are
administered in a coordinated fashion. A differentiated services administered in a coordinated fashion. A differentiated services
domain can represent different administrative domains or autonomous domain can represent different administrative domains or autonomous
systems, different trust regions, different network technologies systems, different trust regions, different network technologies
(e.g., cell/frame), hosts and routers, etc. Also DS domain. (e.g., cell/frame), hosts and routers, etc. Also DS domain.
Nichols, et. al. Expires: February 1999 [Page 5]
Differentiated Services Field: the IPv4 header TOS octet or the Differentiated Services Field: the IPv4 header TOS octet or the
IPv6 Traffic Class octet when interpreted in conformance with the IPv6 Traffic Class octet when interpreted in conformance with the
definition given in this document. Also DS field. definition given in this document. Also DS field.
Mechanism: The implementation of a per-hop behavior according to a Mechanism: The implementation of one or more per-hop behaviors
particular algorithm. according to a particular algorithm.
Microflow: a single instance of an application-to-application flow of Microflow: a single instance of an application-to-application flow of
Nichols, et. al. Expires: April 1999 [Page 5]
packets which is identified by source address, destination address, packets which is identified by source address, destination address,
protocol id, and source port, destination port (where applicable). protocol id, and source port, destination port (where applicable).
Per-hop Behavior (PHB): a description of the externally observable Per-hop Behavior (PHB): a description of the externally observable
forwarding treatment applied at a differentiated services-compliant forwarding treatment applied at a differentiated services-compliant
node to a behavior aggregate. The description of a PHB SHOULD node to a behavior aggregate. The description of a PHB SHOULD
be sufficiently detailed to allow the construction of predictable be sufficiently detailed to allow the construction of predictable
services. services, as documented in [ARCH].
Per-hop Behavior Group: a set of one or more PHBs that can only be Per-hop Behavior Group: a set of one or more PHBs that can only be
meaningfully specified and implemented simultaneously, due to a meaningfully specified and implemented simultaneously, due to a
common constraint applying to all PHBs in the set such as a queue common constraint applying to all PHBs in the set such as a queue
servicing or queue management policy. Also PHB Group. servicing or queue management policy. Also PHB Group.
Traffic Conditioning: control functions that can be applied to a Traffic Conditioning: control functions that can be applied to a
behavior aggregate, application flow, or other operationally useful behavior aggregate, application flow, or other operationally useful
subset of traffic, e.g., routing updates. These MAY include subset of traffic, e.g., routing updates. These MAY include
metering, policing, shaping, and packet marking. Traffic metering, policing, shaping, and packet marking. Traffic
conditioning is used to enforce service level agreements between conditioning is used to enforce service level agreements between
domains and to condition traffic to receive a differentiated service domains and to condition traffic to receive a differentiated service
within a domain by marking packets with the appropriate codepoint in within a domain by marking packets with the appropriate codepoint in
the DS field and by monitoring and altering the temporal the DS field and by monitoring and altering the temporal
characteristics of the aggregate where necessary. characteristics of the aggregate where necessary. See [ARCH].
Traffic Conditioner: an entity which performs traffic conditioning Traffic Conditioner: an entity that performs traffic conditioning
functions and which MAY contain meters, policers, shapers, and functions and which MAY contain meters, policers, shapers, and
markers. Traffic conditioners are typically deployed in DS boundary markers. Traffic conditioners are typically deployed in DS boundary
nodes only. nodes (i.e., not in interior nodes of a DS domain).
Service: a description of the overall treatment 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 Service: a description of the overall treatment of (a subset of) a
select which packets are to be added to behavior aggregates. customer's traffic across a particular domain, across a set of
Aggregates receive differentiated treatment in a DS domain and interconnected DS domains, or end-to-end. Service descriptions are
traffic conditioners MAY alter the temporal characteristics of the covered by administrative policy and services are constructed by
aggregate to conform to some requirements. A packet's DS field is applying traffic conditioning to create behavior aggregates which
used to designate the packet's behavior aggregate and is subsequently 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.
Nichols, et. al. Expires: February 1999 [Page 6] To summarize, classifiers and traffic conditioners are used to select
used to determine which forwarding treatment the packet receives. A which packets are to be added to behavior aggregates. Aggregates
DS field classifier which can select a differential output queue receive differentiated treatment in a DS domain and traffic
servicing discipline (or PHB) based on the codepoint in the DS field conditioners MAY alter the temporal characteristics of the aggregate
SHOULD be included in all network nodes in a DS domain. The to conform to some requirements. A packet's DS field is used to
classifiers and traffic conditioners at DS boundaries are configured designate the packet's behavior aggregate and is subsequently used to
in accordance with some service specification, a matter of determine which forwarding treatment the packet receives. A behavior
administrative policy outside the scope of this document. 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.
Nichols, et. al. Expires: April 1999 [Page 6]
Additional differentiated services definitions are given in [ARCH]. Additional differentiated services definitions are given in [ARCH].
3. Differentiated Services Field Definition 3. Differentiated Services Field Definition
A new header field, called the DS field, is defined, which is A replacement header field, called the DS field, is defined, which is
intended to supersede the existing definitions of the IPv4 TOS octet intended to supersede the existing definitions of the IPv4 TOS octet
[RFC791] and the IPv6 Traffic Class octet [IPv6]. [RFC791] and the IPv6 Traffic Class octet [IPv6].
Six bits of the DS field are used as a codepoint (DSCP) to select the 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 PHB a packet experiences at each node. A two-bit currently unused
(CU) field is reserved and may be assigned later, e.g., for explicit (CU) field is reserved and its definition and interpretation are
congestion notification. The value of the CU bits are ignored by outside the scope of this document. The value of the CU bits are
differentiated services-compliant nodes when determining the per-hop ignored by differentiated services-compliant nodes when determining
behavior to apply to a received packet. the per-hop behavior to apply to a received packet.
The DS field structure is presented below: The DS field structure is presented below:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| DSCP | CU | | DSCP | CU |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
DSCP: differentiated services codepoint DSCP: differentiated services codepoint
CU: currently unused 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- Implementors should note that the DSCP field is six bits wide. DS-
compliant nodes MUST select PHBs by matching against the entire 6- 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 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 index which is used to select a particular packet handling mechanism
which has been implemented in that device. The DSCP field is defined which has been implemented in that device. The value of the CU field
as an unstructured field to facilitate the definition of future per- MUST be ignored by PHB selection. The DSCP field is defined as an
hop behaviors. unstructured field to facilitate the definition of future per-hop
behaviors.
With some exceptions noted below, the mapping of codepoints to PHBs With some exceptions noted below, the mapping of codepoints to PHBs
MUST be configurable. A DS-compliant node MUST support the logical MUST be configurable. A DS-compliant node MUST support the logical
equivalent of a configurable mapping table from codepoints to PHBs. equivalent of a configurable mapping table from codepoints to PHBs.
PHB specifications MUST include a recommended default codepoint, but PHB specifications MUST include a recommended default codepoint,
operators MAY choose to use different codepoints, either in addition which MUST be unique for codepoints in the standard space (see Sec.
to or in place of the recommended default. Note that if operators do 6). Implementations should support the recommended codepoint-to-PHB
so choose, re-marking of DS fields will be necessary at mappings in their default configuration. Operators may choose to use
administrative boundaries even if the same PHBs are implemented on 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.
Nichols, et. al. Expires: February 1999 [Page 7] Nichols, et. al. Expires: April 1999 [Page 7]
both sides of the boundary. See [ARCH] for further discussion of re- See [ARCH] for further discussion of re-marking.
marking. The recommended default codepoint for a PHB MUST be unique
for codepoints in the standard space (see Sec. 6).
The exceptions to general configurability are for codepoints 'xxx000' The exceptions to general configurability are for codepoints 'xxx000'
and are noted in Secs. 4.2.2 and 4.3. and are noted in Secs. 4.2.2 and 4.3.
Packets received with an unrecognized codepoint SHOULD be forwarded Packets received with an unrecognized codepoint SHOULD be forwarded
as if they were marked for the Default behavior (see Sec. 4). Such as if they were marked for the Default behavior (see Sec. 4), and
packets MUST NOT cause the network node to crash. 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 The structure of the DS field shown above is incompatible with the
existing definition of the IPv4 TOS octet in [RFC791, RFC1349]. The existing definition of the IPv4 TOS octet in [RFC791]. The
presumption is that DS domains protect themselves by deploying re- presumption is that DS domains protect themselves by deploying re-
marking boundary nodes, as should networks using the RFC 791 marking boundary nodes, as should networks using the RFC 791
Precedence designations. Correct operational procedure SHOULD follow Precedence designations. Correct operational procedure SHOULD follow
[RFC791], which states: "If the actual use of these precedence [RFC791], which states: "If the actual use of these precedence
designations is of concern to a particular network, it is the designations is of concern to a particular network, it is the
responsibility of that network to control the access to, and use of, responsibility of that network to control the access to, and use of,
those precedence designations." Validating the value of the DS field those precedence designations." Validating the value of the DS field
at DS boundaries is sensible in any case since an upstream node can at DS boundaries is sensible in any case since an upstream node can
easily set it to any random value. DS domains which are not suitably easily set it to any random value. DS domains that are not isolated
isolated by a re-marking boundary node may deliver unpredictable by suitably configured boundary nodes may deliver unpredictable
service. service.
Nodes MAY rewrite the DS field as needed to provide a desired local Nodes MAY rewrite the DS field as needed to provide a desired local
or end-to-end service. Specifications of DS field translations at or end-to-end service. Specifications of DS field translations at
DS boundaries are the subject of service level agreements between DS boundaries are the subject of service level agreements between
providers and users, and are outside the scope of this document. providers and users, and are outside the scope of this document.
Standardized PHBs allow providers to build their services from a Standardized PHBs allow providers to build their services from a
well-known set of packet forwarding treatments that can be expected well-known set of packet forwarding treatments that can be expected
to be present in the equipment of many vendors. to be present in the equipment of many vendors.
skipping to change at page 10, line ? skipping to change at page 10, line ?
already in widespread use (e.g., those satisfying the IPv4 Precedence already in widespread use (e.g., those satisfying the IPv4 Precedence
queueing requirements specified in [RFC1812]), and we wish to permit queueing requirements specified in [RFC1812]), and we wish to permit
their continued use in DS-compliant nodes. In addition, there are their continued use in DS-compliant nodes. In addition, there are
some codepoints that correspond to historical use of the IP some codepoints that correspond to historical use of the IP
Precedence field and we reserve these codepoints to map to PHBs that 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 meet the general requirements specified in Sec. 4.2.2.2, though the
specific differentiated services PHBs mapped to by those codepoints specific differentiated services PHBs mapped to by those codepoints
MAY have additional specifications. MAY have additional specifications.
No attempt is made to maintain backwards compatibility with the "DTR" No attempt is made to maintain backwards compatibility with the "DTR"
or TOS bits of the IPv4 TOS octet, as defined in [RFC791, RFC1349]. or TOS bits of the IPv4 TOS octet, as defined in [RFC791].
Nichols, et. al. Expires: February 1999 [Page 8] Nichols, et. al. Expires: April 1999 [Page 8]
4.1 A Default PHB 4.1 A Default PHB
A "default" PHB MUST be available in a DS-compliant node. This is A "default" PHB MUST be available in a DS-compliant node. This is
the common, best-effort forwarding behavior available in existing the common, best-effort forwarding behavior available in existing
routers as standardized in [RFC1812]. When no other agreements are routers as standardized in [RFC1812]. When no other agreements are
in place, it is assumed that packets belong to this aggregate. Such in place, it is assumed that packets belong to this aggregate. Such
packets MAY be sent into a network without adhering to any particular packets MAY be sent into a network without adhering to any particular
rules and the network will deliver as many of these packets as rules and the network will deliver as many of these packets as
possible and as soon as possible, subject to other resource policy possible and as soon as possible, subject to other resource policy
constraints. A reasonable implementation of this PHB would be a constraints. A reasonable implementation of this PHB would be a
skipping to change at page 10, line ? skipping to change at page 10, line ?
that reserves some minimal resources (e.g, buffers, bandwidth) for that reserves some minimal resources (e.g, buffers, bandwidth) for
Default behavior aggregates. This permits senders that are not Default behavior aggregates. This permits senders that are not
differentiated services-aware to continue to use the network in the differentiated services-aware to continue to use the network in the
same manner as today. The impact of the introduction of same manner as today. The impact of the introduction of
differentiated services into a domain on the service expectations of differentiated services into a domain on the service expectations of
its customers and peers is a complex matter involving policy its customers and peers is a complex matter involving policy
decisions by the domain and is outside the scope of this document. decisions by the domain and is outside the scope of this document.
The RECOMMENDED codepoint for the Default PHB is the bit pattern The RECOMMENDED codepoint for the Default PHB is the bit pattern
'000000'; the value '000000' MUST map to a PHB that meets these '000000'; the value '000000' MUST map to a PHB that meets these
specifications. The codepoint chosen for Default behavior is specifications. The codepoint chosen for Default behavior is
compatible with existing practice [RFC791, RFC1349]. Where a compatible with existing practice [RFC791]. Where a codepoint is
codepoint is not mapped to a standardized or local use PHB, it SHOULD not mapped to a standardized or local use PHB, it SHOULD be mapped to
be mapped to the Default PHB. the Default PHB.
A "default" PHB MUST be available in a DS-compliant node. This is
A packet initially marked for the Default behavior MAY be re-marked 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 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, that it will be forwarded using a different PHB within that domain,
possibly subject to some negotiated agreement between the peering possibly subject to some negotiated agreement between the peering
domains. domains.
4.2 Once and Future IP Precedence Field Use 4.2 Once and Future IP Precedence Field Use
We wish to maintain some form of backward compatibility with present 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. 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 Routers exist that use the IP Precedence field to select different
per-hop forwarding treatments quite similarly to the use proposed per-hop forwarding treatments in a similar way to the use proposed
here for the DSCP field. Thus, a simple prototype differentiated here for the DSCP field. Thus, a simple prototype differentiated
services architecture can be quickly deployed by appropriately services architecture can be quickly deployed by appropriately
configuring these routers. Further, IP systems today understand the configuring these routers. Further, IP systems today understand the
location of the IP Precedence field, and thus if these bits are used location of the IP Precedence field, and thus if these bits are used
in a similar manner as DS-compliant equipment is deployed, in a similar manner as DS-compliant equipment is deployed,
significant failures are not likely during early deployment. In significant failures are not likely during early deployment. In
other words, strict DS-compliance need not be ubiquitous even within 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 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 are employed in a manner similar to, or subsuming, the deployed uses
of the IP Precedence field. of the IP Precedence field.
Nichols, et. al. Expires: February 1999 [Page 9] Nichols, et. al. Expires: April 1999 [Page 9]
4.2.1 IP Precedence History and Evolution in Brief 4.2.1 IP Precedence History and Evolution in Brief
The IP Precedence field is something of a forerunner of the DS field. The IP Precedence field is something of a forerunner of the DS field.
IP Precedence, and the IP Precedence Field, were first defined in IP Precedence, and the IP Precedence Field, were first defined in
[RFC791]. The values that the three-bit IP Precedence Field might [RFC791]. The values that the three-bit IP Precedence Field might
take were assigned to various uses, including network control take were assigned to various uses, including network control
traffic, routing traffic, and various levels of privilege. The least traffic, routing traffic, and various levels of privilege. The least
level of privilege was deemed "routine traffic". In [RFC791], the level of privilege was deemed "routine traffic". In [RFC791], the
notion of Precedence was defined broadly as " An independent measure notion of Precedence was defined broadly as "An independent measure
of the importance of this datagram." Not all values of the IP of the importance of this datagram." Not all values of the IP
Precedence field were assumed to have meaning across boundaries, for Precedence field were assumed to have meaning across boundaries, for
instance "The Network Control precedence designation is intended to instance "The Network Control precedence designation is intended to
be used within a network only. The actual use and control of that be used within a network only. The actual use and control of that
designation is up to each network." [RFC791] designation is up to each network." [RFC791]
Although early BBN IMPs implemented the Precedence feature, early Although early BBN IMPs implemented the Precedence feature, early
commercial routers and UNIX IP forwarding code generally did not. As commercial routers and UNIX IP forwarding code generally did not. As
networks became more complex and customer requirements grew, networks became more complex and customer requirements grew,
commercial router vendors developed ways to implement various kinds commercial router vendors developed ways to implement various kinds
skipping to change at page 11, line 7 skipping to change at page 11, line 7
map to PHBs meeting these minimum requirements. The PHBs mapped to map to PHBs meeting these minimum requirements. The PHBs mapped to
by these codepoints MAY have a more detailed list of specifications by these codepoints MAY have a more detailed list of specifications
in addition to the required ones stated here. Other codepoints MAY 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 map to these same PHBs. We refer to this set of codepoints as the
Class Selector Codepoints, and the minimum requirements for PHBs that Class Selector Codepoints, and the minimum requirements for PHBs that
these codepoints may map to are called the Class Selector PHB these codepoints may map to are called the Class Selector PHB
Requirements. Requirements.
4.2.2.1 The Class Selector Codepoints 4.2.2.1 The Class Selector Codepoints
A specification of the packet forwarding treatments selected by the
The DS field values of 'xxx000|xx', or DSCP = 'xxx000' and CU The DS field values of 'xxx000|xx', or DSCP = 'xxx000' and CU
subfield unspecified, are reserved as a set of Class Selector subfield unspecified, are reserved as a set of Class Selector
Codepoints. PHBs which are mapped to by these codepoints MUST Codepoints. PHBs which are mapped to by these codepoints MUST
satisfy the Class Selector PHB requirements in addition to preserving satisfy the Class Selector PHB requirements in addition to preserving
the Default PHB requirement on codepoint '000000' (Sec. 4.1). the Default PHB requirement on codepoint '000000' (Sec. 4.1).
4.2.2.2 The Class Selector PHB Requirements 4.2.2.2 The Class Selector PHB Requirements
We refer to a Class Selector Codepoint with a larger numerical value We refer to a Class Selector Codepoint with a larger numerical value
than another Class Selector Codepoint as having a higher relative than another Class Selector Codepoint as having a higher relative
order while a Class Selector Codepoint with a smaller numerical value order while a Class Selector Codepoint with a smaller numerical value
than another Class Selector Codepoint is said to have a lower than another Class Selector Codepoint is said to have a lower
relative order. The set of PHBs mapped to by the eight Class relative order. The set of PHBs mapped to by the eight Class
Selector Codepoints MUST yield at least two independently forwarded Selector Codepoints MUST yield at least two independently forwarded
classes of traffic, and PHBs selected by a Class Selector Codepoint classes of traffic, and PHBs selected by a Class Selector Codepoint
SHOULD give packets a probability of timely forwarding that is not SHOULD give packets a probability of timely forwarding that is not
lower than that given to packets marked with a Class Selector lower than that given to packets marked with a Class Selector
codepoint of lower relative order, assuming roughly equivalent loads codepoint of lower relative order, under reasonable operating
for each behavior aggregate. A discarded packet is considered to be conditions and traffic loads. A discarded packet is considered to be
an extreme case of untimely forwarding. In addition, PHBs selected an extreme case of untimely forwarding. In addition, PHBs selected
by codepoint '11x000' MUST give packets a preferential forwarding by codepoints '11x000' MUST give packets a preferential forwarding
treatment by comparison to the PHB selected by codepoint '000000' to treatment by comparison to the PHB selected by codepoint '000000' to
preserve the common usage of IP Precedence values '110' and '111' for preserve the common usage of IP Precedence values '110' and '111' for
routing traffic. routing traffic.
Where the relative loads of two or more Class Selector behavior
aggregates are not roughly equivalent, the relative ordering of the
observed forwarding behaviors is dependent on details of the PHB
specification that are not defined here. A discarded packet is
considered to be an extreme case of untimely forwarding.
Further, PHBs selected by distinct Class Selector Codepoints SHOULD Further, PHBs selected by distinct Class Selector Codepoints SHOULD
be independently forwarded; that is, packets marked with different be independently forwarded; that is, packets marked with different
Class Selector Codepoints MAY be re-ordered. A network node MAY Class Selector Codepoints MAY be re-ordered. A network node MAY
enforce limits on the amount of the node's resources that can be enforce limits on the amount of the node's resources that can be
utilized by each of these PHBs. utilized by each of these PHBs.
PHB groups whose specification satisfy these requirements are PHB groups whose specification satisfy these requirements are
referred to as Class Selector Compliant PHBs. referred to as Class Selector Compliant PHBs.
The Class Selector PHB Requirements on codepoint '000000' are The Class Selector PHB Requirements on codepoint '000000' are
skipping to change at page 12, line 33 skipping to change at page 12, line 28
recommended codepoints. A network administrator might configure recommended codepoints. A network administrator might configure
those routers to select the Strict Priority Queueing PHBs with those routers to select the Strict Priority Queueing PHBs with
codepoints 'xxx000' in conformance with the requirements of this codepoints 'xxx000' in conformance with the requirements of this
document. document.
As a further example, another vendor might employ a CBQ mechanism in As a further example, another vendor might employ a CBQ mechanism in
its routers. The CBQ mechanism could be used to implement the Strict its routers. The CBQ mechanism could be used to implement the Strict
Priority Queueing PHBs as well as a set of Class Selector Compliant 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 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 of PHBs that did no more than meet the minimum Class Selector PHB
requirements. More examples are given in the Appendix. requirements.
4.3 Summary 4.3 Summary
This document defines codepoints 'xxx000' as the Class Selector This document defines codepoints 'xxx000' as the Class Selector
codepoints, where PHBs selected by these codepoints MUST meet the codepoints, where PHBs selected by these codepoints MUST meet the
Class Selector PHB Requirements described in Sec. 4.2.2.2. This is Class Selector PHB Requirements described in Sec. 4.2.2.2. This is
done to preserve a useful level of backward compatibility with done to preserve a useful level of backward compatibility with
current uses of the IP Precedence field in the Internet without current uses of the IP Precedence field in the Internet without
unduly limiting future flexibility. In addition, codepoint '000000' unduly limiting future flexibility. In addition, codepoint '000000'
is used as the Default PHB value for the Internet and, as such, is is used as the Default PHB value for the Internet and, as such, is
skipping to change at page 13, line 10 skipping to change at page 13, line 4
The behavioral characteristics of a PHB are to be standardized, and The behavioral characteristics of a PHB are to be standardized, and
not the particular algorithms or the mechanisms used to implement not the particular algorithms or the mechanisms used to implement
them. A node may have a (possibly large) set of parameters that can 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 be used to control how packets are scheduled onto an output interface
(e.g., N separate queues with settable priorities, queue lengths, (e.g., N separate queues with settable priorities, queue lengths,
round-robin weights, drop algorithm, drop preference weights and round-robin weights, drop algorithm, drop preference weights and
thresholds, etc). To illustrate the distinction between a PHB and a thresholds, etc). To illustrate the distinction between a PHB and a
mechanism, we point out that Class Selector Compliant PHBs might be mechanism, we point out that Class Selector Compliant PHBs might be
implemented by several mechanisms, including: strict priority implemented by several mechanisms, including: strict priority
queueing, WFQ, WRR, or variants [HPFQA, RPS, DRR], or CBQ [CBQ], in queueing, WFQ, WRR, or variants [HPFQA, RPS, DRR], or CBQ [CBQ], in
isolation or in combination (see Appendix). isolation or in combination.
PHBs may be specified individually, or as a group (a single PHB is a 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 special case of a PHB group). A PHB group usually consists of a set
two or more PHBs that can only be meaningfully specified and two or more PHBs that can only be meaningfully specified and
implemented simultaneously, due to a common constraint applying to implemented simultaneously, due to a common constraint applying to
each PHB within the group, such as a queue servicing or queue each PHB within the group, such as a queue servicing or queue
management policy. A PHB group specification SHOULD describe management policy. A PHB group specification SHOULD describe
conditions under which a packet might be re-marked to select another conditions under which a packet might be re-marked to select another
PHB within the group. It is RECOMMENDED that PHB implementations do PHB within the group. It is RECOMMENDED that PHB implementations do
not introduce any packet re-ordering within a microflow. PHB group not introduce any packet re-ordering within a microflow. PHB group
skipping to change at page 14, line 5 skipping to change at page 13, line 49
or configurations to enable service differentiation within their or configurations to enable service differentiation within their
networks, and are free to configure the node parameters in whatever networks, and are free to configure the node parameters in whatever
way that is appropriate for their service offerings and traffic way that is appropriate for their service offerings and traffic
engineering objectives. Over time certain common per-hop behaviors engineering objectives. Over time certain common per-hop behaviors
are likely to evolve (i.e., ones that are particularly useful for are likely to evolve (i.e., ones that are particularly useful for
implementing end-to-end services) and these MAY be associated with implementing end-to-end services) and these MAY be associated with
particular EXP/LU PHB codepoints in the DS field, allowing use across particular EXP/LU PHB codepoints in the DS field, allowing use across
domain boundaries (see Sec. 6). These PHBs are candidates for future domain boundaries (see Sec. 6). These PHBs are candidates for future
standardization. standardization.
It is RECOMMENDED that standardized PHBs be specified in accordance
with the guidelines set out in [ARCH].
6. IANA Considerations 6. IANA Considerations
The DSCP field within the DS field is capable of conveying 64 The DSCP field within the DS field is capable of conveying 64
distinct codepoints. The codepoint space is divided into three pools distinct codepoints. The codepoint space is divided into three pools
for the purpose of codepoint assignment and management: a pool of 32 for the purpose of codepoint assignment and management: a pool of 32
RECOMMENDED codepoints (Pool 1) to be assigned by Standards Action as 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 defined in [CONS], a pool of 16 codepoints (Pool 2) to be reserved
experimental or Local Use (EXP/LU) as defined in [CONS], and a pool for experimental or Local Use (EXP/LU) as defined in [CONS], and a
of 16 codepoints (Pool 3) which are initially available for pool of 16 codepoints (Pool 3) which are initially available for
experimental or local use, but which should be preferentially experimental or local use, but which should be preferentially
utilized for standardized assignments if Pool 1 is ever exhausted. utilized for standardized assignments if Pool 1 is ever exhausted.
The pools are defined in the following table (where 'x' refers to The pools are defined in the following table (where 'x' refers to
either '0' or '1'): either '0' or '1'):
Pool Codepoint space Assignment Policy Pool Codepoint space Assignment Policy
---- --------------- ----------------- ---- --------------- -----------------
1 xxxxx0 Standards Action 1 xxxxx0 Standards Action
2 xxxx11 EXP/LU 2 xxxx11 EXP/LU
skipping to change at page 14, line 43 skipping to change at page 14, line 39
compatibility with IP Precedence as defined in [RFC791] and as compatibility with IP Precedence as defined in [RFC791] and as
deployed in some current equipment. deployed in some current equipment.
7. Security Considerations 7. Security Considerations
This section considers security issues raised by the introduction of This section considers security issues raised by the introduction of
differentiated services, primarily the potential for denial-of- differentiated services, primarily the potential for denial-of-
service attacks, and the related potential for theft of service by service attacks, and the related potential for theft of service by
unauthorized traffic (Section 7.1). Section 7.2 addresses the unauthorized traffic (Section 7.1). Section 7.2 addresses the
operation of differentiated services in the presence of IPsec operation of differentiated services in the presence of IPsec
including its interaction with IPsec tunnel mode and other tunneling including its interaction with IPsec tunnel mode and other tunnelling
protocols. More extensive treatment of the security concerns raised protocols. See [ARCH] for more extensive treatment of the security
by the overall differentiated services architecture are discussed in concerns raised by the overall differentiated services architecture.
[ARCH].
7.1 Theft and Denial of Service 7.1 Theft and Denial of Service
The primary goal of differentiated services is to allow different The primary goal of differentiated services is to allow different
levels of service to be provided for traffic streams on a common levels of service to be provided for traffic streams on a common
network infrastructure. A variety of techniques may be used to network infrastructure. A variety of techniques may be used to
achieve this, but the end result will be that some packets receive achieve this, but the end result will be that some packets receive
different (e.g., better) service than others. The mapping of network different (e.g., better) service than others. The mapping of network
traffic to the specific behaviors that result in different (e.g., traffic to the specific behaviors that result in different (e.g.,
better or worse) service is indicated primarily by the DS codepoint, better or worse) service is indicated primarily by the DS codepoint,
and hence an adversary may be able to obtain better service by and hence an adversary may be able to obtain better service by
modifying the codepoint to values indicating behaviors used for modifying the codepoint to values indicating behaviors used for
enhanced services or by injecting packets with such codepoint values. enhanced services or by injecting packets with such codepoint values.
Taken to its limits, such theft of service becomes a denial-of- Taken to its limits, such theft of service becomes a denial-of-
service attack when the modified or injected traffic depletes the service attack when the modified or injected traffic depletes the
resources available to forward it and other traffic streams. resources available to forward it and other traffic streams.
The defense against this class of theft- and denial-of-service The defense against this class of theft- and denial-of-service
attacks consists of the combination of traffic conditioning at attacks consists of the combination of traffic conditioning at DS
network boundaries with security and integrity of the network domain boundaries with security and integrity of the network
infrastructure within a DS domain. Network boundary nodes MUST infrastructure within a DS domain. DS domain boundary nodes MUST
ensure that all traffic entering the domain is marked with codepoint ensure that all traffic entering the domain is marked with codepoint
values appropriate to the traffic and the domain, remarking the values appropriate to the traffic and the domain, remarking the
traffic with new codepoint values if necessary. These DS boundary traffic with new codepoint values if necessary. These DS boundary
nodes are the primary line of defense against theft- and denial-of- nodes are the primary line of defense against theft- and denial-of-
service attacks based on modified codepoints, as success of any such service attacks based on modified codepoints, as success of any such
attack indicates that the codepoints used by the attacking traffic attack indicates that the codepoints used by the attacking traffic
were inappropriate. An important instance of a boundary node is that were inappropriate. An important instance of a boundary node is that
any traffic-originating node within a DS domain is the initial any traffic-originating node within a DS domain is the initial
boundary node for that traffic. Interior nodes in a DS domain rely boundary node for that traffic. Interior nodes in a DS domain rely
on DS codepoints to associate traffic with the forwarding PHBs, and on DS codepoints to associate traffic with the forwarding PHBs, and
are not required to check codepoint values before using them. As a are NOT REQUIRED to check codepoint values before using them. As a
result, the interior nodes depend on the correct operation of the DS result, the interior nodes depend on the correct operation of the DS
domain to prevent the arrival of traffic with inappropriate domain boundary nodes to prevent the arrival of traffic with
codepoints that would disrupt operation of the domain. inappropriate codepoints or in excess of provisioned levels that
would disrupt operation of the domain.
7.2 IPsec and Tunnelling Interactions 7.2 IPsec and Tunnelling Interactions
The IPsec protocol, as defined in [ESP, AH], does not include the IP 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 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 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 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 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 IPsec integrity check to fail. As a consequence, IPsec does not
provide any defense against an adversary's modification of the DS provide any defense against an adversary's modification of the DS
skipping to change at page 16, line 21 skipping to change at page 16, line 18
exiting the tunnel, and hence MUST ensure that the resulting traffic exiting the tunnel, and hence MUST ensure that the resulting traffic
has appropriate DS codepoints. has appropriate DS codepoints.
When IPsec tunnel egress decapsulation processing includes a When IPsec tunnel egress decapsulation processing includes a
sufficiently strong cryptographic integrity check of the encapsulated sufficiently strong cryptographic integrity check of the encapsulated
packet (where sufficiency is determined by local security policy), packet (where sufficiency is determined by local security policy),
the tunnel egress node can safely assume that the DS field in the 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. 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 An important consequence is that otherwise insecure links within a DS
domain can be secured by a sufficiently strong IPsec tunnel. This domain can be secured by a sufficiently strong IPsec tunnel. This
analysis and its implications apply to any tunneling protocol that analysis and its implications apply to any tunnelling protocol that
performs integrity checks, but the level of assurance of the inner performs integrity checks, but the level of assurance of the inner
header's DS field depends on the strength of the integrity check header's DS field depends on the strength of the integrity check
performed by the tunneling protocol. In the absence of sufficient performed by the tunnelling protocol. In the absence of sufficient
assurance for a tunnel that may transit nodes outside the current DS assurance for a tunnel that may transit nodes outside the current DS
domain (or is otherwise vulnerable), the encapsulated packet MUST be domain (or is otherwise vulnerable), the encapsulated packet MUST be
treated as if it had arrived at a boundary from outside the DS treated as if it had arrived at a boundary from outside the DS
domain. domain.
8. Acknowledgements 8. Acknowledgements
The authors would like to acknowledge the Differentiated Services The authors would like to acknowledge the Differentiated Services
Working Group for discussions which helped shape this document. Working Group for discussions which helped shape this document.
9. References 9. References
[AH] S. Kent and R. Atkinson, "IP Authentication Header", [AH] S. Kent and R. Atkinson, "IP Authentication Header",
Internet Draft <draft-ietf-ipsec-auth-header-07.txt>, Internet Draft <draft-ietf-ipsec-auth-header-07.txt>,
July 1998. July 1998.
[ARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Wang, and [ARCH] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and
W. Weiss, "An Architecture for Differentiated Services", W. Weiss, "An Architecture for Differentiated Services",
Internet Draft <draft-ietf-diffserv-arch-01.txt>, Internet Draft <draft-ietf-diffserv-arch-02.txt>,
August 1998. October 1998.
[CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource [CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource
Management Models for Packet Networks", IEEE/ACM Management Models for Packet Networks", IEEE/ACM
Transactions on Networking, Vol. 3 no. 4, pp. 365-386, Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
August 1995. August 1995.
[CLARK] D. Clark and W. Fang, "Explicit Allocation of Best
Effort Packet Delivery Service",
http://diffserv.lcs.mit.edu/Papers/exp-alloc-ddc-wf.pdf
[CONS] T. Narten and H. Alvestrand, "Guidelines for Writing an [CONS] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", Internet Draft IANA Considerations Section in RFCs", Internet Draft
<draft-iesg-iana-considerations-04.txt>, May 1998. <draft-iesg-iana-considerations-06.txt>, September 1998.
[DRR] M. Shreedhar and G. Varghese, Efficient Fair Queueing [DRR] M. Shreedhar and G. Varghese, Efficient Fair Queueing
using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995. using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995.
[ESP] S. Kent and R. Atkinson, "IP Encapsulating Security [ESP] S. Kent and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", Internet Draft Payload (ESP)", Internet Draft
<draft-ietf-ipsec-esp-v2-06.txt>, July 1998. <draft-ietf-ipsec-esp-v2-06.txt>, July 1998.
[HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair [HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair
Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996. Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996.
skipping to change at page 17, line 29 skipping to change at page 17, line 22
[IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6 [IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", Internet Draft (IPv6) Specification", Internet Draft
<draft-ietf-ipngwg-ipv6-spec-v2-01.txt>, November 1997. <draft-ietf-ipngwg-ipv6-spec-v2-01.txt>, November 1997.
[RFC791] Information Sciences Institute, "Internet Protocol", [RFC791] Information Sciences Institute, "Internet Protocol",
Internet RFC 791, September 1981. Internet RFC 791, September 1981.
[RFC1122] R. T. Braden, "Requirements for Internet hosts - [RFC1122] R. T. Braden, "Requirements for Internet hosts -
communication layers", Internet RFC 1122, October 1989. communication layers", Internet RFC 1122, October 1989.
[RFC1349] P. Almquist, "Type of Service in the Internet Protocol
Suite", Internet RFC 1349, July 1992.
[RFC1812] F. Baker, editor, "Requirements for IP Version 4 [RFC1812] F. Baker, editor, "Requirements for IP Version 4
Routers", Internet RFC 1812, June 1995. Routers", Internet RFC 1812, June 1995.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", Internet RFC 2119, March 1997. Requirement Levels", Internet RFC 2119, March 1997.
[RPS] D. Stiliadis and A. Varma, "Rate-Proportional Servers: [RPS] D. Stiliadis and A. Varma, "Rate-Proportional Servers:
A Design Methodology for Fair Queueing Algorithms", IEEE/ A Design Methodology for Fair Queueing Algorithms", IEEE/
ACM Trans. on Networking, April 1998. ACM Trans. on Networking, April 1998.
Appendix. Examples of Class Selector Compliant PHB Implementations
This appendix shows how four different mechanisms can be used to
implement Class Selector Compliant PHBs.
A.1 Priority Queues
This approach employs eight queues where each of the eight codepoints
maps to a different queue. Queues are serviced in priority order so
that each queue, from the perspective of the next lower priority
queue, implements a "low loss, low delay" forwarding behavior. As an
alternative, one can employ four queues, where bits 0 and 1 of the
codepoint are used to select the queue. Bit 2 of the codepoint is
used as a drop preference within the queue. RED is used within the
queues according to its usual parameters, but with in-profile traffic
having a higher min-threshold and max-threshold than out-of-profile
traffic, and therefore experiencing a higher probability of timely
delivery [CLARK]. Out-of-profile traffic should consider the
presence of lower order in-profile traffic in the calculation of drop
probability.
The strength of this second approach is that packet order is
maintained within each precedence queue, but higher ordered traffic
may be sent before lower ordered traffic (since lower ordered traffic
within a queue may be dropped). It has a weakness, however, in that
apart from admission control and policing, it affords lower
precedence traffic no assurance of eventual transmission.
A.2 Weighted Link-Share Queueing
Like the previous example, this approach employs a queue per
codepoint, but each queue is emptied at some non-zero rate, in round-
robin order by means of some appropriate algorithm [HPFQA, RPS, DRR],
rather than being given simple priority service.
The strength of this approach is that higher ordered traffic is, on
average, queued for a shorter duration than lower ordered traffic,
assuming roughly equivalent relative loads for each order. It also
avoids the lockout issue that priority queuing systems may
experience. A counter-intuitive scenario can occur, however, if a
high rate queue is heavily utilized while a lower rate queue is
under-utilized; a packet directed to the lower rate queue can
actually be better protected from loss and variation in delay when
placed in an empty or very short queue.
A.3 Virtual Circuit or Virtual Channel Selection
The difference between this approach and Weighted Link-Share Queuing
is somewhat academic. If one has a serial line to a routing
neighbor, and manages the link using a link sharing algorithm, the
link sharing algorithm in some sense emulates the way the line would
behave if it were in reality a number of different lines, or if it
were one channelized line. In a virtual circuit selection model, the
emulation becomes reality - one deploys a set of rate-limited VCs to
a routing neighbor, and uses them in the same way one would otherwise
have used round-robin queues.
The strengths and weaknesses are very similar to those of Weighted
Link-Share Queuing, except that this allows one to capitalize on the
capabilities of a link layer such as ATM or Frame Relay.
A.4 Priority Buffer Management
This approach assigns buffer occupancy thresholds for each codepoint,
with the threshold for a higher ordered codepoint being no lower than
the threshold for a lower ordered codepoint. Under link congestion,
packets marked with a lower ordered codepoint are discard before
those packets marked with a higher ordered codepoint. The
thresholding mechanism might be deterministic, or based on average
queue occupancies and statistical discard probability weighting
functions [CLARK].
Authors' Addresses Authors' Addresses
Kathleen Nichols Kathleen Nichols
Bay Networks Architecture Lab Cisco Systems
4401 Great America Parkway 170 West Tasman Drive
SC01-04 San Jose, CA 95134-1706
Santa Clara, CA 95052-8185 Phone: +1-408-525-4857
Phone: +1-408-495-3252 E-mail: kmn@cisco.com
Fax: +1-408-495-1299
E-mail: knichols@baynetworks.com
Steven Blake Steven Blake
Torrent Networking Technologies Torrent Networking Technologies
2221 Broadbirch Drive 3000 Aerial Center, Suite 140
Silver Spring, MD 20904 Morrisville, NC 27560
Phone: +1-301-625-1600 Phone: +1-919-468-8466 x232
E-mail: slblake@torrentnet.com E-mail: slblake@torrentnet.com
Fred Baker Fred Baker
Cisco Systems Cisco Systems
519 Lado Drive 519 Lado Drive
Santa Barbara, California 93111 Santa Barbara, CA 93111
Phone: +1-408-526-4257 Phone: +1-408-526-4257
E-mail: fred@cisco.com E-mail: fred@cisco.com
David L. Black David L. Black
The Open Group EMC Corporation
11 Cambridge Center 35 Parkwood Drive
Cambridge, MA 02142 Hopkinton, MA 01748
Phone: +1-617-621-7347 Phone: +1-508-435-1000 x76140
E-mail: d.black@opengroup.org E-mail: black_david@emc.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 68 change blocks. 
224 lines changed or deleted 139 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/