Internet DRAFT - draft-ietf-diffserv-headers
draft-ietf-diffserv-headers
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 01:54:09 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 08 May 1998 01:32:00 GMT
ETag: "2ed799-69bb-35526090"
Accept-Ranges: bytes
Content-Length: 27067
Connection: close
Content-Type: text/plain
INTERNET-DRAFT Kathleen Nichols
Diffserv Working Group Bay Networks Architecture Lab
Expires: November 1998 Steven Blake
IBM Microelectronics
May 1998
Definition of the Differentiated Services Field (DS Byte)
in the IPv4 and IPv6 Headers
<draft-ietf-diffserv-headers-00.txt>
Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
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).
Abstract
Differentiated services are intended to provide scalable service
discrimination in the Internet without the need for per-flow state
and signaling at every hop. A variety of services may be built from
a small, well-defined set of building blocks which are deployed in
network nodes. The services may be either end-to-end or intra-
domain. Services can be provided by a combination of:
- setting bits in an IP header field at network edges and
administrative boundaries,
- using those bits to determine how packets are forwarded by the
routers inside the network, and
- conditioning the marked packets at network boundaries in accordance
with the requirements or rules of each service.
This document defines the IP header field, called the DS (for
differentiated services) byte. In IPv4, it takes the place of the TOS
octet; in IPv6, it takes the place of the Traffic Class octet. A
differentiated services-capable network node includes a classifier
Nichols, Blake Expires: November 1998 [Page 1]
INTERNET-DRAFT Differentiated Services May 1998
that selects packets based on the value of the DS byte and is capable
of delivering the specific packet forwarding treatment corresponding
to that value. This document defines two packet forwarding
treatments, or per-hop behaviors. Setting of the DS byte and other
conditioning of the dynamic behavior of marked packets need only be
performed at network boundaries and may vary in complexity.
For a more complete understanding of differentiated services, this
document should be read along with its companion documents, the
differentiated services architecture [ARCH], the differentiated
services framework [FWK], and other documents which specify
additional per-hop behaviors, such as [Baker].
1. Introduction
The DS byte is used to mark a packet to receive a particular
forwarding treatment, or per-hop behavior, on nodes along its path.
Marking is performed by traffic conditioners at network boundaries,
including the edges of the network (first hop router or source host)
and administrative boundaries. Traffic conditioners may include the
primitives of classification, marking, policing and shaping (these
mechanisms are described in [ARCH]). Services are realized by the
use of particular traffic conditioning at boundaries coupled with the
concatenation of per-hop behaviors along the transit path of the
traffic (services are discussed in [FWK]). A goal of the
differentiated services architecture is to specify these building
blocks for future extensibility, both of the number and type of the
building blocks and of the services built from them.
Terminology used in this draft is defined in Sec. 2. The
differentiated services byte definition (DS byte) is given in Sec. 3.
In Sec. 4, two specific per-hop behaviors are defined. Sec. 5
presents guidelines for per-hop behavior standardization. Sec. 6
discusses guidelines for allocation of per-hop behavior codepoints.
Sec. 7 covers security considerations. We present two example
services which can be built from these differentiated services
primitives in the Appendix.
This document is a concise description of the DS byte and its uses.
It is intended to be read along with its companion documents, the
differentiated services architecture [ARCH], the differentiated
services framework [FWK], and other documents which specify
additional per-hop behaviors, such as [Baker].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Nichols, Blake Expires: November 1998 [Page 2]
INTERNET-DRAFT Differentiated Services May 1998
2. Terminology Used in This Document
Behavior aggregate: a collection of packets with the same codepoint
crossing a boundary in a particular direction. The terms "aggregate"
and "behavior aggregate" are used interchangeably in this document.
Boundary: Where two network "clouds" are linked; the "clouds" can
represent different administrative domains or autonomous systems,
different trust regions, different network technologies (e.g., cell/
frame), hosts and routers, etc. A boundary can be further sub-
divided into exit and entry nodes, where the exit/entry nodes are the
upstream/downstream nodes of a boundary link in a given traffic
direction.
Codepoint: a specific value of the PHB field in the DS byte.
DS byte: the IPv4 header TOS octet or the IPv6 Traffic Class octet
when interpreted in conformance with the definition given in this
document.
Mechanism: The implementation of a per-hop behavior according to a
particular algorithm.
Network edge: refers to a particular boundary node, the edge of the
differentiated services-compliant area. This typically is at the
ingress to the first-hop differentiated services-aware router (or
network node) a host's packets traverse, or at the egress of the
last-hop differentiated services-aware router or network node packets
traverse before arriving at a host. This is sometimes referred to as
the boundary at a leaf router. The network edge might be co-located
with a host, subject to local policy.
Per-hop Behavior: a description of the externally observable
forwarding treatment applied at a differentiated services-enabled
node to a behavior aggregate.
Service: a description of the overall treatment of a customer's
traffic within a particular domain or end-to-end.
Traffic conditioner: an entity which performs traffic conditioning
functions and which may contain header classifiers, meters, policers,
shapers, and markers. Traffic conditioners are typically deployed in
boundary nodes only.
Traffic conditioning: control functions that can be applied to a
behavior aggregate, application flow, or other operationally useful
subset of traffic, e.g., routing updates. These may include header
classification, metering, policing, shaping, and packet marking.
Traffic conditioning is used to enforce service level agreements
between domains and to condition traffic to receive a differentiated
service within a domain.
Nichols, Blake Expires: November 1998 [Page 3]
INTERNET-DRAFT Differentiated Services May 1998
To summarize, the DS byte is used to designate behaviors. A DS byte
classifier and per-hop behaviors based on those classifications are
required in all network nodes of a differentiated services-capable
network. More extensive traffic conditioners may appear at
boundaries. Multiple services can be supported by a single per-hop
behavior used in concert with a range of traffic conditioners.
3. Differentiated Services Byte Definition
A new header field, called the DS byte, is defined. The DS byte then
overrides existing definitions of the IPv4 TOS octet [RFC791] and the
IPv6 Traffic Class octet [IPv6].
Six bits of the DS byte are used to define the per-hop behavior (PHB)
a packet experiences. A two-bit currently unused (CU) field is
reserved and may be assigned later, e.g., for explicit congestion
notification [ECN]. The value of the CU bits MUST be ignored by
differentiated services-compliant nodes when determining the per-hop
behavior to apply to a received packet.
The DS byte structure is presented below:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| PHB | CU |
+---+---+---+---+---+---+---+---+
PHB: per-hop behavior
CU: currently unused
Implementors should note that the PHB field is 6 bits wide. Routers
MUST identify PHBs by matching against the entire 6-bit PHB field,
e.g., by treating the value or "codepoint" of the PHB field as a
table index or a switch/case statement variable which is used to
select a particular packet handling mechanism which has been
implemented in that device. Although the IANA may assume some
structure within the PHB field when assigning values for new per-hop
behaviors, we define it as an unstructured field to facilitate the
definition of future per-hop behaviors.
Packets received with an unrecognized codepoint SHOULD be forwarded
as if they were marked for the Default behavior (see Sec. 4).
The structure of the DS byte shown above is incompatible with the
existing definition of the IPv4 TOS octet in [RFC791, RFC1349]. The
presumption is that differentiated services-aware networks protect
themselves by deploying re-marking boundary nodes, as should networks
using the RFC 791 Precedence designations. Correct operational
procedure should follow [RFC791], which states: "If the actual use of
Nichols, Blake Expires: November 1998 [Page 4]
INTERNET-DRAFT Differentiated Services May 1998
these precedence designations is of concern to a particular network,
it is the responsibility of that network to control the access to,
and use of, those precedence designations." Validating the value of
the DS byte at network boundaries is sensible in any case since an
upstream node can easily set it to any random value. Differentiated
services-enabled networks which are not suitably isolated by a
re-marking boundary node may deliver unpredictable service. A
companion document [Baker] describes how a minimal necessary amount
of compatibility with RFC 791 Precedence can be maintained under use
of the DS byte.
4. Initial Per-Hop Behavior Definitions
Two per-hop behaviors are already in widespread use and we propose
them for standardization: Default (DE) is the common, best-effort
forwarding behavior available in existing routers and is already
standardized in [RFC1812]. Expedited Forwarding (EF) is a "high
priority" forwarding behavior such as might be used for delay
sensitive traffic such as audio and video. The codepoints for these
two behaviors are shown below:
Codepoint Behavior name
--------- -------------
000000 Default (DE)
000010 Expedited Forwarding (EF)
and the behaviors are defined as follows:
Default: a DE-marked packet is queued for an outgoing interface
according to the availability of buffer resources and according to
any active queue management policy that may be implemented [ACTIVE].
It is not required that all arriving packets are seen at the output,
but it is RECOMMENDED that the aggregate of packets with this marking
not be completely starved. Forwarding requirements are as soon as
possible, and the corresponding output bandwidth requirements are as
much as possible, subject to the other constraints of the router's
scheduling and buffer management sub-systems [CCBES]. The Default
behavior is intended to closely approximate the best-effort behavior
of existing routers. The codepoint chosen for Default behavior is
compatible with existing practice [RFC791, RFC1349].
A packet originating from a node and marked for the Default behavior
may be re-marked with another PHB codepoint at a downstream network
boundary to enable preferential forwarding within that network,
possibly subject to some negotiated agreement.
Expedited Forwarding: for traffic levels of EF-marked packets which
are a small fraction of the link rate of an outgoing interface, the
Nichols, Blake Expires: November 1998 [Page 5]
INTERNET-DRAFT Differentiated Services May 1998
implementation of Expedited Forwarding should exhibit the following
behavioral characteristics: low absolute delay, low delay variation,
and extremely low loss, irrespective of the rate of non-EF-marked
traffic which is forwarded through that same outgoing interface. The
delay and loss characteristics should be similar to that observed by
a single packet traversing an otherwise idle router, and should not
vary significantly as the rate of non-EF-marked traffic is increased.
The maximum rate of EF-marked traffic which can be forwarded on an
outgoing link while satisfying the desired behavioral characteristics
is implementation-dependent. The Expedited Forwarding behavior can
be realized by a variety of mechanisms, including strict priority
queueing, WFQ or variants [HPFQA], weighted round-robin queueing with
a large weight for the EF queue, or CBQ [CBQ].
The Expedited Forwarding behavior may be used to implement services
requiring low delay and low jitter. Service guarantees for this
class of traffic SHOULD depend on conformance to some rate and
burstiness constraints which are enforced by traffic conditioners at
network boundaries, possibly subject to some negotiated agreement.
EF-marked aggregates which are in excess of these constraints may
have some or all of their packets delayed (by a shaper) or discarded.
Note that conforming implementations will commonly employ separate
scheduler queues for DE- and EF-marked packets. Thus it should be
expected that packet streams which include both DE- and EF-marked
packets may suffer packet reordering when traversing a conforming
router.
5. Per-Hop Behavior Standardization Guidelines
Thirty-two PHB codepoints are reserved for standardization, and 32
codepoints are reserved for experimental or local use (EXP/LU)
(see Sec. 6 for further details).
The behavioral characteristics of a PHB are to be standardized, and
not the algorithms or the mechanisms used to implement them. A
router may have a (possibly large) set of parameters that can be used
to control how packets are scheduled onto an output interface (e.g.,
N separate queues with settable priorities, queue lengths, round-
robin weights, drop algorithm, drop preference weights and
thresholds, etc). To illustrate the distinction between a PHB and a
mechanism, we point out that the EF PHB might be implemented by
several mechanisms, including: strict priority queueing, WFQ or
variants [HPFQA], weighted round-robin queueing with a large weight
for the EF queue, or CBQ [CBQ].
Router vendors are free to offer whatever parameters and capabilities
are deemed useful or marketable. When a particular, standardized PHB
is implemented in a router, a vendor may use any algorithm that
satisfies the definition of the PHB according to the standard. The
router's capabilities and its particular configuration determine the
Nichols, Blake Expires: November 1998 [Page 6]
INTERNET-DRAFT Differentiated Services May 1998
different ways that packets can be treated.
Service providers are not required to use the same router mechanisms
or configurations to enable service differentiation within their
networks, and are free to configure the router parameters in whatever
way that is appropriate for their service offerings and traffic
engineering objectives. Over time certain common per-hop behaviors
are likely to evolve (i.e., ones that are particularly useful for
implementing end-to-end services) and these may be associated with
particular EXP/LU PHB codepoints in the DS byte, allowing use across
domain boundaries (see Sec. 6). These PHBs are candidates for future
standardization.
Only those per-hop behaviors that are not described by an existing
PHB standard, and have been implemented, deployed, and shown to be
useful, should be standardized. Since current experience with
differentiated services is quite limited, it is premature to
hypothesize the exact specification of these per-hop behaviors. This
specification has left room in the codepoint space to allow for
evolution, thus the defined space is intentionally sparse.
6. IANA Considerations
The PHB field in the DS byte is capable of conveying 64 distinct
codepoints. The codepoint space is divided into three pools for the
purpose of codepoint assignment and management: a pool of 32
codepoints (Pool 1) to be assigned by Standards Action as defined in
[CONS], a pool of 16 codepoints (Pool 2) to be reserved for
experimental or Local Use (EXP/LU) as defined in [CONS], and a pool
of 16 codepoints (Pool 3) which are initially available for
experimental or local use, but which should be preferentially
utilized for standardized assignments if Pool 1 is ever exhausted.
The pools are defined in the following table (where 'x' refers to
either '0' or '1'):
Pool Codepoint space Assignment Policy
---- --------------- -----------------
1 xxxxx0 Standards Action
2 xxxx11 EXP/LU
3 xxxx01 EXP/LU (*)
(*) may be utilized for future Standards Action allocations as
necessary
This document defines two per-hop behaviors for standardization, and
recommends the assignment of two codepoints (000000 and 000010) which
are drawn from Pool 1 above.
Nichols, Blake Expires: November 1998 [Page 7]
INTERNET-DRAFT Differentiated Services May 1998
The IANA should note that a companion document may recommend
assignment of the codepoint space xxxx00 within Pool 1 for use by
per-hop behaviors which provide a minimal level of backwards
compatibility with IP Precedence as defined in [RFC791].
7. Security Considerations
The IP Security Authentication Header (AH) does not cover the IPv4
TOS octet or the IPv6 Traffic Class field in the integrity check
value computation [AH]. This behavior is in fact essential for the
deployment of differentiated services since the value of the DS byte
may be changed in transit so that the source host does not know what
value will be delivered to the destination host. Also, since the
network is free to ignore the DS byte, end-to-end integrity of a DS
byte value does not guarantee that a differentiated service has been
delivered. Separate measurement and assurance mechanisms are needed
to ensure that any negotiated differentiated services are being
provided.
Packets marked for Expedited Forwarding receive priority service
relative to packets with other markings. The rate of EF-marked
packets MUST be regulated to prevent starvation of other traffic.
EF-marked traffic received across a boundary link SHOULD be
authenticated (e.g., either by IPsec, by header classification, or by
aggregate policing).
Additional security issues of the general differentiated services
architecture are discussed in [ARCH].
8. Acknowledgements
The authors would like to acknowledge the Differentiated Services
Working Group for discussions which helped shape this document.
9. References
[ACTIVE] B. Braden, et. al., "Recommendations on Queue Management
and Congestion Avoidance in the Internet", Internet RFC
2309, April 1998.
[AH] S. Kent and R. Atkinson, "IP Authentication Header",
Internet Draft <draft-ietf-ipsec-auth-header-05.txt>,
March 1998.
[ARCH] Differentiated Services Architecture Document (work in
preparation).
Nichols, Blake Expires: November 1998 [Page 8]
INTERNET-DRAFT Differentiated Services May 1998
[Baker] F. Baker, S. Brim, T. Li, F. Kastenholz, S. Jagannath,
and J. Renwick, "IP Precedence in Differentiated
Services Using the Assured Service", Internet Draft
<draft-diff-serv-precedence-00.txt>, April 1998.
[CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource
Management Models for Packet Networks", IEEE/ACM
Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
August 1995.
[CONS] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", Internet Draft
<draft-iesg-iana-considerations-03.txt>, March 1998.
[CCBES] C. Lefelhocz, B. Lyles, S. Shenker, and L. Zhang,
"Congestion Control for Best-Effort Service: Why We Need
a New Paradigm", IEEE Network, Vol. 10, no. 1, January
1996.
[ECN] K. Ramakrishnan and S. Floyd, "A Proposal to Add Explicit
Congestion Notification (ECN) to IPv6 and to TCP",
Internet Draft <draft-kksjf-ecn-00.txt>, November 1997.
[FWK] Differentiated Services Framework Document (work in
preparation).
[HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair
Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996.
[IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", Internet Draft
<draft-ietf-ipngwg-ipv6-spec-v2-01.txt>, November 1997.
[RFC791] Information Sciences Institute, "Internet Protocol",
Internet RFC 791, September 1981.
[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
Routers", Internet RFC 1812, June 1995.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", Internet RFC 2119, March 1997.
[2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
http://www-nrg.ee.lbl.gov/papers/2bitarch.pdf.
Nichols, Blake Expires: November 1998 [Page 9]
INTERNET-DRAFT Differentiated Services May 1998
Appendix A. Service Examples in this Framework
We present two example services which may be implemented using the
per-hop behaviors defined in this document. We do not attempt to
define "quality of service" for applications nor do we make
assumptions about what service a particular application might use.
Thus, although we give some example uses, we do not characterize the
services as being "for real-time video" or "for file transfer data".
Instead, we characterize a service by the type of performance packets
of that service can expect from the network. Any IP application can
utilize either of these services; the choice is up to the customer.
Service: Best Effort
PHBs used: Default
Service definition: "like today" (as soon as possible; as much as
possible [CCBES]). At the network edge, packets of the Best Effort
aggregate should be marked with the Default PHB (though this is also
the forwarding treatment that a packet with an unknown marking should
receive). This might be accomplished by marking all packets at the
network edge for the Default PHB which can be changed if the packet
header matches an multi-field classifier set up at the network edge.
Who/how to use this: The basic service of the Internet, what one gets
when merely buying connectivity.
Service: Premium
PHBs used: Expedited Forwarding
Service definition: Premium service is a peak-limited, extremely low-
delay service, resembling a leased line [2BIT]. At the network edge,
where a Premium aggregate is first created, it must be either shaped
or policed to a rate with no more than a two-packet burst. A policer
for Premium service is set to drop packets which exceed the
configured peak rate. For this service, the peak rate of the Premium
aggregate across any boundary must be specified and the rate must be
smaller than the link capacity (in practice, it is expected to be a
good deal less than the link capacity). Policing to this rate is
expected at the ingress of any domain and the policing action taken
may be one of two possibilities only: 1) drop the over-rate packet
and 2) hold the over-rate packet until it will be in compliance with
the peak rate (shaping).
Who/how to use this: Voice-over-IP "trunk", videoconference, fixed
size transfer in fixed time, virtual leased line, low delay
applications.
Nichols, Blake Expires: November 1998 [Page 10]
INTERNET-DRAFT Differentiated Services May 1998
Authors' Addresses
Steven Blake
IBM Microelectronics
C5BA 660/HH007
800 Park Offices Drive
Research Triangle Park, NC 27709
Phone: +1-919-254-2030
Fax: +1-919-254-3047
E-mail: slblake@raleigh.ibm.com
Kathleen Nichols
Bay Networks Architecture Lab
4401 Great America Parkway
SC01-04
Santa Clara, CA 95052-8185
Phone: +1-408-495-3252
Fax: +1-408-495-1299
E-mail: knichols@baynetworks.com
Nichols, Blake Expires: November 1998 [Page 11]
