view Side-By-Side changes
May
August 1998
An Architecture for Differentiated Services
<draft-ietf-diffserv-arch-00.txt>
<draft-ietf-diffserv-arch-01.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).
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This document defines an architecture for implementing scalable
service differentiation in the Internet. This architecture achieves
scalability by aggregating traffic classification state which is
conveyed by means of IP-layer packet marking using the DS field
[DSFIELD]. Packets are classified and marked to receive a particular
per-hop forwarding behavior on routers nodes along their path. Sophisticated
classification, marking, policing, and shaping operations need only
be implemented at network boundaries or hosts. Network resources are
Blake, et. al. Expires: February 1999 [Page 1]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
allocated to traffic streams by service provisioning policies which
govern how traffic is marked and conditioned upon entry to a
differentiated services-capable network, and how that traffic is
Black, et. al. Expires: November 1998 [Page 1]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
forwarded within that network. A wide variety of services can be
implemented on top of these building blocks.
This document should be read along
Table of Contents
1. Introduction ................................................. 3
1.1 Overview ................................................. 3
1.2 Terminology ............................................... 4
1.3 Requirements .............................................. 8
1.4 Comparisons with its companion documents, the Other Approaches ......................... 9
2. Differentiated Services Architectural Model .................. 11
2.1 Differentiated Services Domain ............................ 11
2.1.1 DS Boundary Nodes and Interior Nodes .................. 12
2.1.2 DS Ingress Node and Egress Node ....................... 12
2.2 Differentiated Services Region ............................ 13
2.3 Traffic Classification and Conditioning ................... 13
2.3.1 Classifiers ........................................... 13
2.3.2 Traffic Profiles ...................................... 14
2.3.3 Traffic Conditioners .................................. 15
2.3.3.1 Meters ............................................ 15
2.3.3.2 Markers ........................................... 15
2.3.3.3 Shapers ........................................... 16
2.3.3.4 Droppers .......................................... 16
2.3.4 Location of Traffic Conditioners and MF Classifiers ... 16
2.3.4.1 Within the differentiated services framework [DSFWK], Source Domain .......................... 16
2.3.4.2 At the definition Boundary of the a DS field [DSFIELD], Domain .................... 17
2.3.4.3 In non-DS-Capable Domains ......................... 17
2.3.4.4 In Interior DS Nodes .............................. 17
2.4 Per-Hop Behaviors ......................................... 18
2.5 Network Resource Allocation ............................... 19
3. Per-Hop Behavior Specification Guidelines .................... 20
4. Interoperability with Non-Differentiated Services-Compliant
Nodes ........................................................ 23
5. Multicast Considerations ..................................... 25
6. Security and other documents which specify per-hop
behaviors, such as [Baker]. Tunneling Considerations ........................ 26
6.1 Theft and Denial of Service ............................... 26
6.2 IPsec and Tunneling Interactions .......................... 28
6.3 Auditing .................................................. 30
7. Acknowledgements ............................................. 30
8. References ................................................... 31
Authors Addresses' ............................................... 33
Full Copyright Statement ......................................... 34
Blake, et. al. Expires: February 1999 [Page 2]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
1. Introduction
1.1 Overview
This document defines an architecture for implementing scalable
service differentiation in the Internet. A "Service" is taken to
signify defines some
significant characteristics of packet transmission in one direction
across a set of one or more paths within a network. These
characteristics may be specified in quantitative or statistical terms
of throughput, delay, jitter, and/or loss, or may otherwise be
specified in terms of some relative priority of access to network
resources. Service differentiation is desired to accommodate
heterogeneous application requirements and user expectations, and to
permit differentiated pricing of Internet service.
This architecture is composed of a number of functional elements
implemented in network nodes, including a small set of well-defined per-hop
forwarding behaviors, packet classification functions, and traffic
conditioning functions including classification, metering, marking, shaping, and
policing. This architecture achieves scalability by implementing
complex classification and conditioning functions only at network edge
boundary nodes, and by applying per-hop behaviors to aggregates of
traffic which have been appropriately marked using the DS field in
the IPv4 or IPv6 headers [DSFIELD]. Per-hop behaviors are defined to
permit a reasonably granular means of allocating buffer and bandwidth
resources at each node among competing traffic streams. Per-application Per-
application flow or per-customer forwarding state need not be
maintained within the core of the network. Service provisioning and A distinction is
maintained between:
o the service provided to a traffic conditioning policies are
sufficiently decoupled from aggregate,
o the forwarding conditioning functions and per-hop behaviors within the
network interior used to permit a wide realize
services,
o the DS field value (DS codepoint) used to mark packets to select a
per-hop behavior, and
o the particular node implementation mechanisms which realize a per-
hop behavior.
Service provisioning and traffic conditioning policies are
sufficiently decoupled from the forwarding behaviors within the
network interior to permit implementation of a wide variety of
service behaviors to be
implemented, behaviors, with room for future expansion.
Section
This architecture only provides service differentiation in one
direction of traffic flow and is therefore asymmetric. Development
of a complementary symmetric architecture is a topic of current
research but is outside the scope of this document; see for example
[EXPLICIT].
Blake, et. al. Expires: February 1999 [Page 3]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
Sect. 1.2 is a glossary of terms used within this document.
Section
Sec. 1.3 lists requirements for addressed by this architecture, and Section
Sec. 1.4 provides a brief comparison to other approaches for
service differentiation. Section Sec. 2 discusses the components of the
architecture in detail. Section Sec. 3 proposes requirements guidelines for per-hop
behavior specifications. Section Sec. 4 discusses interoperability issues
with nodes and networks which do not implement differentiated
services as defined in this document and in [DSFIELD]. Section Sec. 5
discusses issues with multicast traffic (this section is currently left for future
study). Section service delivery. Sec. 6 addresses
security and tunnel considerations.
Black, et. al. Expires: November 1998 [Page 2]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
This document should be read along with its companion documents, the
differentiated services framework [DSFWK], the definition of the DS
field [DSFIELD], and other documents which specify per-hop behaviors,
such as [Baker]. behaviors.
It has been heavily influenced by the thoughtful proposals of
previous authors [Clark97, Ellesson, [Ellesson, EXPLICIT, Ferguson, Heinanen, SIMA, 2BIT,
Weiss].
1.2 Terminology
This section gives a general conceptual overview of the terms used
in this document. Some of these terms are more precisely defined in
later sections of this document. The choice of terms and definitions
were influenced by [MPLSFWK].
Behavior Aggregate (BA) a DS behavior aggregate.
BA classifier a classifier that selects packets based
only on the contents of the DS-field. Such
classifiers are used in DS interior nodes,
and are typically used for policing at a DS
ingress node. field.
Boundary link a link connecting the edge nodes of two
domains.
Classifier a logical element of traffic conditioning
that an entity which selects packets based on
the content of packet headers according to
defined rules.
Customer
DS domain behavior aggregate a DS domain that has an SLA in place collection of packets with
another directly attached DS domain (the
provider DS domain) governing the rules by
which traffic from the customer DS domain
will be serviced within the provider same
DS
domain. A single codepoint crossing a link in a
particular direction.
DS domain may be both boundary node a
customer DS node that connects one DS domain and to a provider
node either in another DS domain
for different directions of traffic at the
same time.
Differentiated Services a paradigm for providing quality-of-service
(DS) (QoS) or in the Internet by employing a small,
well-defined set of building blocks from
which a variety of services may be built.
DS behavior aggregate a stream of packets
domain that have the same is not DS
codepoint. capable.
DS field the IPv4 TOS octet or IPv6 Traffic Class
octet when interpreted according capable capable of implementing differentiated
services as described in this architecture;
usually used in reference to
[DSFIELD].
Black, a domain
consisting of DS-compliant nodes.
Blake, et. al. Expires: November 1998 February 1999 [Page 3] 4]
INTERNET-DRAFT An Architecture for Differentiated Services May August 1998
DS capable able codepoint a specific value of the DSCP portion of the
DS field, used to select a PHB.
DS compliant enabled to support differentiated services
functions and behaviors as defined in
[DSFIELD], this document, and other
documents.
DS codepoint a specific bit-pattern of the DS field.
DS edge node a DS node that connects one DS domain
differentiated services documents; usually
used in reference to a node either in another DS domain or in a
domain that is not DS capable.
DS egress node a DS edge node in its role in handling
traffic as it leaves a DS domain.
DS destination host a DS host that acts as a DS egress node. device.
DS domain a DS-capable domain; a contiguous set of
nodes which operate with a common set of
service provisioning policies and PHB
definitions.
DS host egress node a host computer that can perform certain DS boundary node in its role in handling
traffic conditioning functions and
therefore acts as it leaves a special DS edge node. domain.
DS ingress node a DS edge boundary node in its role in handling
traffic as it enters a DS domain.
DS interior node a DS node that is not a DS edge boundary node.
DS field the IPv4 header TOS octet or the IPv6
Traffic Class octet when interpreted in
conformance with the definition given in
[DSFIELD]. The bits of the DSCP field
encode the DS codepoint, while the
remaining bits are currently unused.
DS node a DS capable DS-compliant node.
DS region a set of contiguous DS domains which can
offer differentiated services over paths
across those DS domains.
Downstream DS source host a domain the DS host that acts as domain downstream of traffic flow on
a DS ingress node.
Legacy node boundary link.
Dropper a node which implements IPv4 Precedence as
defined in [RFC791] device that performs dropping.
Dropping the process of discarding packets based on
specified rules; policing.
Legacy node a node which implements IPv4 Precedence as
defined in [RFC791,RFC1812] but which is
otherwise not DS capable. compliant.
Marker a logical element of traffic conditioning device that sets performs marking.
Marking the process of setting the DS codepoint in the DS field
based on defined rules.
MF Classifier
a classifier which selects packets packet based on
the content of some arbitrary number of
header fields; typically some combination
of source address, destination address,
protocol ID, source port and destination
port.
Black, defined rules; pre-
marking, re-marking.
Blake, et. al. Expires: November 1998 February 1999 [Page 4] 5]
INTERNET-DRAFT An Architecture for Differentiated Services May August 1998
Mechanism a specific algorithm or operation (e.g.,
queueing discipline) that is implemented in
a node to realize a set of one or more per-
hop behaviors.
Meter a logical element of traffic conditioning device that measures performs metering.
Metering the process of measuring the temporal
properties (e.g., rate) of a packet traffic stream
selected by a classifier. The
instantaneous state of this process may be
used to affect the operation of a marker,
shaper, or dropper, and/or may be used for
accounting and measurement purposes.
Microflow a single instance of an application-to-
application flow of packets which is
identified by source address, source port,
destination address, destination port and
protocol id.
MF Classifier a multi-field (MF) classifier which selects
packets based on the content of some
arbitrary number of header fields;
typically some combination of source
address, destination address, DS field,
protocol ID, source port and destination
port.
Per-Hop-Behavior (PHB) the externally observable forwarding
behavior applied at a DS capable DS-compliant node to a
DS behavior aggregate.
PHB group a set of one or more PHBs that can only be
meaningfully specified and implemented
simultaneously, due to a common constraint
applying to all PHBs in the set such as a
packet scheduling
queue servicing or discard queue management policy.
A PHB group provides a service building
block that allows a set of related
forwarding behaviors to be specified
together (e.g., four dropping priorities).
A single PHB is a special case of a PHB
group.
Policing the process of applying traffic
conditioning functions such as marking or discarding to packets (by a
dropper) within a traffic stream in
accordance with the state of a
corresponding meter.
Provider meter enforcing a traffic
profile in a TCA.
Blake, et. al. Expires: February 1999 [Page 6]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
Pre-mark to set the DS domain codepoint of a packet prior
to entry into a downstream DS domain that has an SLA in place with
another directly attached domain.
Provider DS domain (the
customer DS domain) governing the rules by
which traffic from the customer DS domain
will be serviced within the DS-capable service provider DS of a source
domain. A single
Re-mark to change the DS domain may be both codepoint of a
customer DS domain and packet,
usually performed by a provider DS domain
for different directions of traffic at the
same time. marker in accordance
with a TCA.
Service the overall treatment of a defined subset
of a customer's traffic within a DS domain
or end-to-end.
Service Level Agreement a service contract between a customer and a
(SLA) service provider that specifies the details
of a TCA and the corresponding forwarding
service
behavior a customer should receive. A
customer may be a user organization (source
domain) or another DS domain.
Black, et. al. Expires: November 1998 [Page 5]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998 domain (upstream
domain).
Service Provisioning a policy which defines how traffic
Policy (SPP) conditioners are configured on DS edge boundary
nodes and how traffic streams are mapped to
DS behavior aggregates to achieve a range
of service behaviors. services.
Shaper a logical element of traffic conditioning device that delays performs shaping.
Shaping the process of delaying packets within a
traffic stream to cause it to conform to
some defined traffic properties. profile.
Source domain a domain which contains the node(s)
originating the traffic receiving a
particular service.
Traffic conditioner an entity that which performs traffic
conditioning functions and which may
contain
classifiers, markers, meters, markers, droppers, and
shapers. Traffic conditioners are typically
deployed in DS boundary nodes only. A
traffic conditioner may re-mark a traffic
stream or may discard or shape packets to
alter the temporal characteristics of the
stream and bring it into compliance with a
traffic profile.
Traffic conditioning control functions performed to enforce
rules specified in a TCA and to prepare
traffic for differentiated services, TCA, including classifying,
metering, marking,
policing, shaping, and shaping. policing.
Blake, et. al. Expires: February 1999 [Page 7]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
Traffic Conditioning an agreement specifying classifier rules
Agreement (TCA) and the any corresponding traffic profiles and
metering, marking, policing discarding and/or shaping
rules which are to apply to the traffic
streams selected by the classifier.
Traffic profile a description of the expected temporal properties
of a traffic stream such as rate and burst
size.
Traffic stream an administratively significant set of one
or more microflows which traverse a path
segment. A traffic stream may consist of
the set of active microflows which are
selected by a particular classifier.
Upstream DS domain the DS domain upstream of traffic flow on a
boundary link.
1.3 Requirements
The history of the Internet has been one of continuous growth in the
number of hosts, the number and variety of applications, and the
capacity of the network infrastructure, and this growth is expected
to continue for the foreseeable future. A scalable architecture for
service differentiation must be able to accommodate this continued
growth.
The following requirements were identified and are addressed in this
architecture:
o must should accommodate a wide variety of service behaviors services and provisioning
policies, extending end-to-end or within a particular (set of)
network(s),
Black, et. al. Expires: November 1998 [Page 6]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
o must should allow decoupling of the service behavior from the particular
application in use,
o must should work with existing applications without the need for
application programming interface changes or host software
modifications (assuming suitable deployment of classifiers,
markers, and other traffic conditioners), conditioning functions),
o must should decouple traffic conditioning and service provisioning
functions from forwarding behaviors implemented within the core
network routers, nodes,
o must should not depend on hop-by-hop application signaling,
o must should require only a small set of forwarding behaviors whose
implementation complexity does not dominate the cost of a network
device, and which will not introduce bottlenecks for
Blake, et. al. Expires: February 1999 [Page 8]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
device, and which will not introduce bottlenecks for future high-
speed system implementations,
o must should avoid per-microflow or per-customer state within core
network
routers, nodes,
o must should utilize only aggregated classification state within the
network core,
o must should permit simple packet classification implementations in core
network routers nodes (BA classifier),
o must should permit reasonable interoperability with non-compliant non-DS-compliant
network nodes,
o must should accommodate incremental deployment.
1.4 Comparisons with Other Approaches
The differentiated services architecture specified in this document
can be contrasted with other existing models of traffic management
and service
differentiation. We classify these alternative models into the
following categories: relative priority, virtual circuit, priority marking, service marking,
label switching, Integrated Services/RSVP, and service marking.
Implementations static per-hop
classification.
Examples of the relative priority marking model include IPv4
Precedence marking as defined in [RFC791], 802.5 Token Ring priority
[TR], and the default interpretation of 802.1p priority traffic classes
[802.1p]. In this model the application, host, or proxy node selects
a relative priority or "precedence" for a packet (e.g., delay or
discard priority), and the network nodes along the transit path apply
the appropriate priority forwarding behavior corresponding to the
priority value within the packet's header. Our architecture can be
considered as a refinement to this model, since we more clearly
specify the role and importance of edge boundary nodes and traffic
conditioners, and since our per-hop behavior model permits more
general forwarding behaviors than relative delay or discard priority.
Black, et. al. Expires: November 1998 [Page 7]
INTERNET-DRAFT
An Architecture for Differentiated Services May 1998
Implementations example of the virtual circuit a service marking model include Frame Relay,
ATM, and MPLS [FRELAY, ATM, PASTE]. is IPv4 TOS as defined in
[RFC1349]. In this model path forwarding
state and traffic management or QoS state is established for traffic
streams on each hop along a path. Traffic aggregates of varying
granularity are associated with a virtual circuit, and packets/cells
within example each virtual circuit are packet is marked with a request for
a "type of service", which may include "minimize delay", "maximize
throughput", "maximize reliability", or "minimize cost". Network
nodes may select routing paths or forwarding label that
is used behaviors which are
suitably engineered to lookup the next hop, the per-hop forwarding behavior, and satisfy the replacement label at each hop. service request. This model permits finer
granularity resource allocation to traffic streams, but the amount
of forwarding state scales linearly with is
subtly different from our architecture. Note that we do not describe
the number of edges use of the
network DS field as an input to route selection. The TOS
markings defined in the best case (assuming multipoint-to-point virtual
circuits), [RFC1349] are very generic and it scales with the square of do not span the number
range of edges in possible service semantics. Furthermore, the worst case, when edge-edge traffic streams with provisioned
resources are employed.
The Integrated Services/RSVP model relies upon traditional datagram
forwarding in the default case, but allows sources and receivers to
exchange signaling messages which establish classification and
forwarding state on each node along the path between them [IntServ,
RSVP]. In the absence of state aggregation, the amount of state on
each node scales in proportion to the ratio of the link rate to the
average reservation size (in bps), multiplied by some fraction of the
link rate which is "reservable". This model also requires
application support for the RSVP signaling protocol.
An example of a service marking model is IPv4 TOS as defined in
[RFC1349]. In this example each packet is marked with a request for
a "type of service", which may include "minimize delay", "maximize
throughput", "maximize reliability", or "minimize cost". Network
nodes may select routing paths or forwarding behaviors which are
suitably provisioned to satisfy the service request. This model is
subtly different from our architecture. The defined TOS markings are
very generic and do not span the range of possible service semantics.
Furthermore, the service request is associated service
request is associated with each individual packet, whereas some
service semantics may depend on the aggregate forwarding behavior of
Blake, et. al. Expires: February 1999 [Page 9]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
a sequence of packets. The service marking model does not easily
accommodate growth in the number and range of future services, services (since
the codepoint space is small) and involves configuration of the
"TOS->forwarding behavior" association in each core network router.
2. Differentiated Services Architectural Model
The differentiated services architecture is based on a simple model
where traffic entering a network node.
Standardizing service markings implies standardizing service
offerings, which is conditioned at outside the edges scope of the
network, and assigned to different behavior aggregates. Each
behavior aggregate is identified with a single DS codepoint. Within IETF. Note that
provisions are made in the core allocation of the network, packets are forwarded according DS codepoint space to the per-
allow for locally significant codepoints which may be used by a
provider to support service marking semantics [DSFIELD].
Examples of the label switching (or virtual circuit) model include
Frame Relay, ATM, and MPLS [FRELAY, ATM, MPLSTE]. In this model path
forwarding state and traffic management or QoS state is established
for traffic streams on each hop along a network path. Traffic
aggregates of varying granularity are associated with a label
switched path at an ingress node, and packets/cells within each label
switched path are marked with a forwarding label that is used to
lookup the next hop node, the per-hop forwarding behavior, and the
replacement label at each hop. This model permits finer granularity
resource allocation to traffic streams, since label values are not
globally significant but are only significant on a single link;
therefore resources can be reserved for the aggregate of packets/
cells received on a link with a particular label, and the label
switching semantics govern the next-hop selection, allowing a traffic
stream to follow a specially engineered path through the network
[MPLSTE]. This improved granularity comes at the cost of additional
management and configuration requirements to establish and maintain
the label switched paths. In addition, the amount of forwarding
state maintained at each node scales in proportion to the number of
edge nodes of the network in the best case (assuming multipoint-to-
point label switched paths), and it scales in proportion with the
square of the number of edge nodes in the worst case, when edge-edge
label switched paths with provisioned resources are employed.
The Integrated Services/RSVP model relies upon traditional datagram
forwarding in the default case, but allows sources and receivers to
exchange signaling messages which establish additional packet
classification and forwarding state on each node along the path
between them [RFC1633, RSVP]. In the absence of state aggregation,
the amount of state on each node scales in proportion to the number
of concurrent reservations, which can be potentially large on high-
speed links. This model also requires application support for the
RSVP signaling protocol. Differentiated services mechanisms can be
utilized to aggregate Integrated Services/RSVP state in the core of
the network [Bernet].
A variant of the Integrated Services/RSVP model eliminates the
requirement for hop-by-hop signaling by utilizing only "static"
classification and forwarding policies which are implemented in each
node along a network path. These policies are updated on
administrative timescales and not in response to the instantaneous
mix of microflows active in the network. The state requirements for
Blake, et. al. Expires: February 1999 [Page 10]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
this variant are potentially worse than those encountered when RSVP
is used, especially in backbone nodes, since the number of static
policies that might be applicable at a node over time may be larger
than the number of active sender-receiver sessions that might have
installed reservation state on a node. Although the support of large
numbers of classifier rules and forwarding policies may be
computationally feasible, the management burden associated with
installing and maintaining these rules on each node within a backbone
network which might be traversed by a traffic stream is substantial.
Although we contrast our architecture with these alternative models
of service differentiation, it should be noted that links and nodes
employing these techniques may be utilized to extend differentiated
services behaviors and semantics across a layer-2 switched
infrastructure (e.g., 802.1p LANs, Frame Relay/ATM backbones)
interconnecting DS nodes, and in the case of MPLS may be used as an
alternative intra-domain implementation technology. The constraints
imposed by the use of a specific link-layer technology in particular
regions of a DS domain (or in a network providing access to DS
domains) may imply the differentiation of traffic on a coarser grain
basis. Depending on the mapping of PHBs to different link-layer
services and the way in which packets are scheduled over a restricted
set of priority classes (or virtual circuits of different category
and capacity), all or a subset of the PHBs in use may be supportable
(or may be indistinguishable).
2. Differentiated Services Architectural Model
The differentiated services architecture is based on a simple model
where traffic entering a network is classified and possibly
conditioned at the boundaries of the network, and assigned to
different behavior aggregates. Each behavior aggregate is identified
by a single DS codepoint. Within the core of the network, packets
are forwarded according to the per-hop behavior associated with the
DS codepoint. In this section, we discuss the key components in within
a differentiated services region, traffic classification and
conditioning functions, and how differentiated services are achieved
through the combination of traffic conditioning and PHB-
Black, et. al. Expires: November 1998 [Page 8]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
based PHB-based
forwarding.
2.1 Differentiated Services Regions
A differentiated services region (DS Region) is a set of contiguous
DS domains, where each DS domain consists of a set of edge nodes and
interior nodes.
2.1.1 DS Domain
A DS domain is a contiguous set of DS nodes which operate with a
common service provisioning policy and set of PHB group definitions. groups implemented
on each node. A DS domain has a well-defined boundary consisting of
DS edge boundary nodes which classify and possibly condition ingress
traffic and to ensure that packets which transit the domain are only
appropriately marked using to select a PHB from one of the PHB groups
supported in within the domain. All nodes inside Nodes within the DS domain select the
forwarding behavior for packets based solely on the their DS codepoint as defined codepoint, mapping
Blake, et. al. Expires: February 1999 [Page 11]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
that value to one of the PHB groups supported in PHBs using either the domain. recommended
codepoint->PHB mapping or a locally customized mapping [DSFIELD].
Inclusion of non-DS capable non-DS-compliant nodes within a DS domain may result in
unpredictable performance and may impede the ability to satisfy SLAs.
service level agreements (SLAs).
A DS domain normally consists of one or more networks under the same
administration,
administration; for example, an organization's intranet or an ISP.
Multiple DS domains may be inter-connected through mutual agreements
to form a DS region. DS domains in a DS region may implement
different PHB groups. However, to permit services which span across
the domains, the peering DS domains must each establish a peering SLA
which includes a Traffic Conditioning Agreement (TCA) which specifies
how transit traffic from one DS domain to another DS domain is
conditioned at the boundary of the two DS domains.
It is possible that several DS domains within a DS region may adopt a
common service provisioning policy and PHB group definitions, thus
eliminating the need for traffic conditioning between those DS
domains. In such cases, those DS domains are effectively under a
single administration and may be considered as a single DS domain.
The administration of the domain is responsible for ensuring that
adequate resources are provisioned and/or reserved to support the
SLAs offered by the domain.
2.1.2
2.1.1 DS Edge Boundary Nodes and Interior Nodes
A DS domain consists of DS edge boundary nodes and DS interior nodes. While DS edge
boundary nodes connect interconnect the DS domain to other DS or non-DS non-DS-
capable domains, whilst DS interior nodes only connect to other DS
interior or edge boundary nodes within the same DS domain.
Both DS edge boundary nodes and interior nodes must be able to forward apply the
appropriate PHB to packets based on the DS codepoint as defined by the PHB groups supported in
the domain; codepoint; otherwise
unpredictable behavior may result. In addition,
Black, et. al. Expires: November 1998 [Page 9]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998 DS edge boundary nodes must
may be able required to perform traffic conditioning functions as described
defined by the TCA a traffic conditioning agreement (TCA) between their DS
domain and the peering domain which they connect to. to (see Sec.
2.3.3).
Interior nodes may be able to perform limited traffic conditioning
functions such as DS codepoint mutation. re-marking. Interior nodes which
implement more complex classification and traffic conditioning
functions are analogous to DS boundary nodes (see Sec. 2.3.4.4).
A host within in a network containing a DS domain may act as a DS edge boundary
node for traffic to
and from applications running on that host. If a host; we therefore
say that the host is embedded in
a within the DS domain and domain. If a host does not act as an edge
a boundary node, then the host's first-
hop router DS node topologically closest to that host
acts as the DS edge boundary node for the that host's traffic.
2.1.3
2.1.2 DS Ingress Node and Egress Node
DS edge boundary nodes may act both as a DS ingress node or and as a DS egress
node.
node for different directions of traffic. Traffic enters a DS domain
at a DS ingress node and leaves a DS domain at a DS egress node. A
DS ingress node is responsible for ensuring that the traffic entering
the DS domain conforms to the any TCA between it and the other domain to
which the ingress node is connected. A DS egress node may perform
traffic conditioning functions on traffic forwarded to a directly
connected
to. peering domain, depending on the details of the TCA between
the two domains. Note that a DS boundary node may act as a DS
interior node for some set of interfaces.
Blake, et. al. Expires: February 1999 [Page 12]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
2.2 Differentiated Services Region
A differentiated services region (DS Region) is a set of one or more
contiguous DS domains. DS regions are capable of supporting
differentiated services along paths which span the domains within the
region.
The DS domains in a DS region may support different PHB groups
internally and different codepoint->PHB mappings. However, to permit
services which span across the domains, the peering DS domains must
each establish a peering SLA which includes a TCA which specifies how
transit traffic from one DS domain to another is conditioned at the
boundary between the two DS domains.
It is possible that several DS domains within a DS region may adopt a
common service provisioning policy and may support a common set of
PHB groups and codepoint mappings, thus eliminating the need for
traffic conditioning between those DS domains.
2.3 Traffic Classification and Conditioning
Differentiated services are extended across a DS domain boundary by
establishing a SLA between an upstream network and a downstream DS egress node may perform
domain. The SLA will generally include a traffic conditioning functions on
agreement which specifies packet classification and re-marking policy
and may also specify traffic forwarded profiles and actions to traffic streams
which are in- or out-of-profile (see Sec. 2.3.2).
The packet classification policy identifies the peering domain, depending on the details subset of
the TCA between two domains.
2.2 Traffic Conditioning
Traffic conditioning functions are performed traffic
which may receive a differentiated service by being conditioned and/
or mapped to one or more behavior aggregates (by DS edge nodes in a codepoint re-
marking) within the DS
domain domain.
Traffic conditioning performs metering, shaping, policing and/or re-
marking to ensure that the traffic entering a the DS domain conforms to
the rules specified in the TCA, in accordance with the domain's
service provisioning policy, and to prepare the traffic for the PHB-
based forwarding treatment in the interior routers.
2.2.1 General Architecture of Traffic Conditioners
A traffic conditioner may contain the following elements: classifier,
meter, marker, and shaper. policy. The classifier and the meter select the
packets within a traffic stream and measure the stream against a extent of traffic profile. The marker and shaper perform control actions conditioning
required is dependent on the packets depending on whether specifics of the traffic stream is within its
associated profile.
A packet stream normally passes service offering, and
may range from simple codepoint re-marking to a classifier first, complex policing and the
matched packets are measured by a meter against the profile as
defined in the TCA.
shaping operations. The packets within the profile may leave the details of traffic conditioner or may be marked by the marker. The packets that conditioning policies
which are out-of-profile may be either marked or shaped according to the
rules specified in the TCA. Note that discard policing can be
performed by a specially configured shaper (see Sec. 2.2.3.4). When
packets leave negotiated between networks is outside the traffic conditioner scope of this
document.
2.3.1 Classifiers
Packet classifiers select packets in a DS ingress node, traffic stream based on the DS
field
content of each packet must be set to one some portion of DS codepoints defined by the PHB groups supported in packet header. We define two types
of classifiers. The BA (Behavior Aggregate) Classifier classifies
packets based on the DS domain.
Black, codepoint only. The MF (Multi-Field)
classifier selects packets based on the value of a combination of one
or more header fields, such as source address, destination address,
Blake, et. al. Expires: November 1998 February 1999 [Page 10] 13]
INTERNET-DRAFT An Architecture for Differentiated Services May August 1998
Fig. 1 shows the block diagram
DS field, protocol ID, source port and destination port numbers, and
other information such as incoming interface.
Classifiers are used to "steer" packets matching some specified rule
to an element of a traffic conditioner. Note that a
traffic conditioner may not necessarily contain all four elements.
For example, packets may pass from for further processing.
Classifiers must be configured by some management procedure in
accordance with the appropriate TCA.
The classifier directly should authenticate the information which it uses to
classify the
marker or shaper (null meter).
+-------+
-->| |---->
+-------+ +-------+ / +-------+
| | | |/ marker
packets -----> | |------>| |-------------------->
| | | |\
+-------+ +-------+ \ +-------+
classifier meter -->| |---->
+-------+
shaper
Fig. 1: Logical View packet (see Sec. 6).
Note that in the event of upstream packet fragmentation, MF
classifiers which examine the contents of transport-layer header
fields may incorrectly classify packet fragments subsequent to the
first. A possible solution to this problem is to maintain
fragmentation state; however, this is not a Traffic Conditioner
2.2.2 Traffic Conditioning Agreement (TCA)
Differentiated services are extended across a DS domain boundary by
establishing a SLA between general solution due to
the customer and provider DS domains. possibility of upstream fragment re-ordering or divergent routing
paths. The
SLA includes a traffic conditioning agreement which usually specifies
traffic profiles and actions policy to in-profile and out-of-profile
packets.
2.2.2.1 apply to packet fragments is outside the scope
of this document.
2.3.2 Traffic Profiles
A traffic profile specifies rules for classifying and measuring the temporal properties of a traffic stream.
stream (selected by a classifier) which is to be mapped to a behavior
aggregate. It identifies what packets are eligible and provides rules for determining whether a particular
packet is in-profile or out-of-
profile. out-of-profile. For example, a profile based
on a token bucket may look like:
codepoint=X, use token-bucket r, b
The above profile indicates that all packets in the behavior
aggregate marked with DS codepoint
X should be measured against a token bucket meter with rate r and
burst size b. In this example out-of-
profile out-of-profile packets are those
packets in the behavior aggregate traffic stream which arrive when insufficient tokens
are available in the bucket. The concept of in- and out-of-profile
can be extended to more than two levels, e.g., multiple levels of
conformance with a profile may be defined and enforced.
Different conditioning actions may be applied to the in-profile
packets and out-of-profile packets, or different accounting actions
may be triggered.
2.2.2.2 Actions to In-Profile and Out-of-Profile Packets In-profile packets may be allowed to enter the DS
domain without further conditioning as they conform to the TCA; conditioning; or, alternatively, their DS field
codepoint may be marked with a new DS codepoint. changed. The latter
Black, et. al. Expires: November 1998 [Page 11]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998 happens when the DS field codepoint
is set to a non-Default value for the first time [DSFIELD], or when
the packets enter a DS domain that uses a different PHB group or
codepoint->PHB mapping policy for this traffic stream, so the DS stream. Out-of-
profile packets may be queued until they are in-profile (shaped),
discarded (policed), marked with a new codepoint has
to (re-marked), or
forwarded unchanged while triggering some accounting procedure. Out-
of-profile packets may be mapped to the new PHB group.
The actions one or more behavior aggregates
that are "inferior" in some dimension of forwarding performance to out-of-profile
the BA which in-profile packets are mapped to.
Blake, et. al. Expires: February 1999 [Page 14]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
Note that a traffic profile is an optional component of a TCA and its
use is dependent on the specifics of the service offering and the
domain's service provisioning policy.
2.3.3 Traffic Conditioners
A traffic conditioner may include delaying contain the following elements: meter,
marker, shaper, and dropper. A traffic stream is selected by a
classifier, which steers the packets until they are in-profile (shaping), discarding the packets,
marking the DS field to a particular codepoint, or triggering some
accounting action.
2.2.3 Components logical instance of a Traffic Conditioner
2.2.3.1 Classifiers
Packet classifiers select packets in a
traffic stream based on conditioner. A meter is used (where appropriate) to measure
the
content of some portion traffic stream against a traffic profile. The state of the meter
with respect to a particular packet header. The classification (e.g., whether it is in- or out-
of-profile) may be based on the DS field only (Behavior Aggregate Classification), or
on any combination of one or several fields in the packet header such
as source address, destination address, DS field, protocol ID, and,
transport-layer header fields such as source port and destination
port numbers (Multi-Field Classification). Classifiers are used to
steer affect a marking, dropping, or shaping
action.
When packets matching some specified rule to another element of exit the traffic conditioner for further processing. Classifiers of a DS boundary node the
DS codepoint of each packet must be
configured by some management procedure in accordance with the
appropriate TCA.
The classifier should authenticate the information which it uses set to
classify an appropriate value.
Fig. 1 shows the packet (see Sec. 6). block diagram of a classifier and traffic
conditioner. Note that a traffic conditioner may not necessarily
contain all four elements. For example, in the event of upstream packet fragmentation, multi-field
classifiers which examine the contents case where no traffic
profile is in effect, packets may only pass through a classifier and
a marker.
+-------+
| |-------------------+
+----->| Meter | |
| | |--+ |
| +-------+ | |
| V V
+------------+ +--------+ +---------+
| | | | | Shaper/ |
packets =====>| Classifier |=====>| Marker |=====>| Dropper |=====>
| | | | | |
+------------+ +--------+ +---------+
Fig. 1: Logical View of transport-layer header
fields may incorrectly classify packet fragments subsequent to the
first. A possible solution to this problem is to maintain
fragmentation state; however, this is not a general solution due to
the possibility of upstream fragment re-ordering or divergent routing
paths.
2.2.3.2 Packet Classifier and Traffic Conditioner
2.3.3.1 Meters
Traffic meters measure the traffic temporal properties of the set stream of
packets selected by a classifier against a traffic profile specified
in the a TCA. A meter indicates passes state information to other conditioning
functions whether to trigger a particular action for each
individual packet which is
either in- or out-of-profile.
A null meter will identify all packets as in-profile. Such a meter
may be used when the traffic profile does not specify conforming rate
or burst parameters.
2.2.3.3 out-of-profile (to some extent).
2.3.3.2 Markers
Packet markers set the DS field of a packet to a particular
codepoint, adding the marked packet to a particular DS behavior
Black,
Blake, et. al. Expires: November 1998 February 1999 [Page 12] 15]
INTERNET-DRAFT An Architecture for Differentiated Services May August 1998
codepoint, adding the marked packet to a particular DS behavior
aggregate. The marker may be configured to mark all packets which
are steered to it to a single codepoint, or may be configured to mark
a packet to one of a set of codepoints within used to select a PHB group in a PHB
group, according to the state of a meter.
2.2.3.4 When the marker changes
the codepoint in a packet it is said to have "re-marked" the packet.
2.3.3.3 Shapers
Shapers delay some or all of the packets in a traffic stream in order
to bring the stream into compliance with its associated a traffic profile. A shaper
usually has a finite-size buffer, and packets may be discarded if
there is not enough sufficient buffer space to hold the delayed
packets.
2.3.3.4 Droppers
Droppers discard some or all of the packets in a traffic stream in
order to bring the stream into compliance with a traffic profile.
This process is know as "policing" the stream. Note that discard policers a dropper
can be implemented as a special case of a shaper by setting the
shaper buffer size to zero (or a few) packets.
2.2.4
2.3.4 Location of Traffic Conditioners and MF Classifiers
Traffic conditioners may be are usually located within a customer DS domain, ingress and
at the egress
boundary of a DS domain. Traffic conditioners nodes, but may also be located in nodes in a non-DS domain.
2.2.4.1 Traffic Conditioners within the interior
of a Customer DS domain, or within a non-DS-capable domain.
2.3.4.1 Within the Source Domain
We define the source domain as the domain containing the node(s)
which originate the traffic receiving a particular service. Traffic
sources and intermediate nodes within a customer DS source domain may perform
traffic classification and conditioning functions. The packets traffic
originating from the
customer DS source domain across a boundary may have their DS field be marked by
the traffic sources directly or by intermediate routers nodes before leaving
the
customer DS domain.
For example, suppose that source domain. This is referred to as initial marking or
"pre-marking".
Consider the example of a customer domain company that has a the policy that the its CEO's
packets should have higher priority. The CEO's host may mark the DS
field of all outgoing packets with a DS codepoint that indicates higher priority.
"higher priority". Alternatively, the first-hop router directly
connected to the CEO's host may classify the traffic and mark the
CEO's packets with the correct DS codepoint. Such high priority
traffic may also be conditioned near the source so that there is a
limit on the amount of high priority traffic forwarded from a
particular source.
There are some advantages to marking the DS field packets close to the traffic
source. First, a traffic source can more easily take an
Blake, et. al. Expires: February 1999 [Page 16]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
application's preferences into account when deciding which packets
should receive better forwarding treatment. Also, classification of
packets is much simpler before the traffic has been aggregated with
packets from other sources, since the number of classification rules
which need to be applied within a single node is reduced.
Since packet marking may be distributed across different multiple nodes, the
customer
source DS domain is responsible for ensuring that the aggregated
traffic towards its provider DS domain conforms to the appropriate
TCA. Additional allocation mechanisms such as bandwidth brokers or
RSVP may be used to dynamically allocate resources for a particular
DS behavior aggregate within the customer's network. provider's network [2BIT,Bernet].
The edge boundary node of the customer DS source domain should also monitor
conformance to the TCA, and triage may police, shape, or re-mark packets as
necessary.
Black, et. al. Expires: November 1998 [Page 13]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
2.2.4.2 Traffic Conditioners at
2.3.4.2 At the Boundary of a DS Domain
Traffic streams may be marked classified, marked, and otherwise conditioned
on either end of a boundary link (the DS egress node of the customer DS upstream
domain or the DS ingress node of the provider DS downstream domain). The TCA
between the domains should specify which domain has responsibility
for mapping traffic streams to DS behavior aggregates and
conditioning those aggregates in conformance with the TCA. However,
a DS ingress node must assume that the incoming traffic may not
conform to the TCA and must be prepared to enforce the TCA in
accordance with local policy.
There is an advantage to performing complex conditioning operations
When packets are pre-marked and conditioned in the customer DS domain since it is then no longer necessary to
divulge the local upstream domain,
potentially fewer classification and service provisioning traffic conditioning rules need
to be supported in the provider downstream DS domain. In this circumstance
the provider downstream DS domain may only need to re-mark or police the
incoming behavior aggregates to enforce the TCA. However, more
sophisticated services which are path- or source-dependent may
require multi-field MF classification in the provider's downstream DS domain's ingress
nodes.
If a DS ingress node is connected to an upstream non-DS-capable
domain, the DS ingress node must be able to perform all necessary
traffic conditioning functions on the incoming traffic.
2.3.4.3 In non-DS-Capable Domains
Traffic sources or intermediate nodes in a non-DS-capable domain may
employ traffic conditioners to pre-mark traffic before it reaches the
ingress of a downstream DS domain. In this way the local policies
for classification and marking may be concealed.
2.3.4.4 In Interior DS Nodes
Although the basic architecture assumes that complex classification
and traffic conditioning functions are located only in a network's
Blake, et. al. Expires: February 1999 [Page 17]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
ingress nodes.
Since packet marking may be distributed across different and egress boundary nodes, deployment of these functions in
the
If a DS ingress node is connected to a non-DS domain, interior of the DS ingress
node must network is not precluded. For example, more
restrictive access policies may be able to perform all enforced on a transoceanic link,
requiring MF classification and traffic conditioning functions functionality
in the upstream node on the incoming traffic.
2.2.4.3 Traffic Conditioners in non-DS Domains
Traffic sources or intermediate nodes in a non-DS domain link. This approach may employ
traffic conditioners have scaling
limits, due to pre-mark traffic before it reaches the
ingress potentially large number of a provider DS domain.
2.3 classification and
conditioning rules that might need to be maintained.
2.4 Per-Hop Behaviors
A per-hop behavior (PHB) is a description of the externally
observable forwarding behavior of a DS node applied to a particular
DS behavior aggregate. "Forwarding behavior" is a general concept in
this context. For example, in the event that only one behavior
aggregate occupies a link, the observable forwarding behavior (i.e.,
loss, delay, jitter) will usually often depend only on the relative loading
of the link (i.e., in the event that the behavior assumes a work-
conserving scheduling discipline). Useful behavioral distinctions
are only mainly observed when multiple behavior aggregates compete for
buffer and bandwidth resources on a node. The PHB is the means by
which a node allocates resources to behavior aggregates, and it is on
top of this basic hop-by-hop resource allocation mechanism that
useful differentiated services may be constructed.
The most simple example of a PHB is one which guarantees a minimal
bandwidth allocation of X% of a link (over some reasonable time
interval) to a behavior aggregate. This PHB can be fairly easily
measured under a variety of competing traffic conditions. A slightly
Black, et. al. Expires: November 1998 [Page 14]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
more complex PHB would guarantee a minimal bandwidth allocation of X%
of a link, with proportional fair sharing of any excess link
capacity. Another simple example is taken from [DSFIELD]; the
Expedited Forwarding PHB. This PHB provides negligible loss, delay,
and delay jitter (similar to that observed by a single packet
traversing an otherwise idle router) for a behavior aggregate which
is the multiplex of multiple peak-rate regulated traffic streams,
under the constraint that the load of the behavior aggregate is a
small fraction of the link capacity. This last constraint is a
consequence of queueing physics; a multiplex of peak-rate regulated
traffic streams may still exhibit arrival burstiness, and the
resulting delay and jitter will only be negligible under the
circumstance where the relative load of the aggregated traffic is
small, even when there is no competing traffic from other behavior
aggregates. In general, the observable behavior of a PHB may depend
on certain constraints on the traffic characteristics of the
associated behavior aggregate, or the characteristics of other
behavior aggregates.
PHBs may be specified in terms of their resource (e.g., buffer,
bandwidth) priority relative to other PHBs, or in terms of their
relative observable traffic characteristics (e.g., delay, loss)
[Baker]. loss).
These PHBs may be used as building blocks to allocate resources and
should be specified as a group (PHB group) for consistency. The priority relationship within a
PHB group groups will tend usually share a common constraint applying to be hierarchical, and the associated DS codepoints should be
assigned in increasing order of relative priority for clarity of
interpretation. each
PHB within the group, such as a packet scheduling or buffer
management policy. The priority relationship between PHBs in the a group may be
in terms of absolute or relative priority (e.g., absolute discard priority) priority by
means of deterministic or may be less
rigid stochastic thresholds), but this is not
required (e.g., higher probability of loss). N equal link shares). A single PHB defined in
isolation is a degenerate form special case of a PHB group.
PHBs are implemented in nodes by means of some buffer management and
packet scheduling mechanisms. PHBs should be are defined in terms of behavior
characteristics relevant to service provisioning policies, and not in
Blake, et. al. Expires: February 1999 [Page 18]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
terms of particular implementation mechanisms. In general, a variety
of implementation mechanisms may be suitable for implementing a
particular PHB group. Furthermore, it is likely that more than one
PHB group may be implemented on a node and utilized within a domain.
PHB groups should be defined such that the proper resource allocation
between groups can be inferred, and integrated mechanisms can be
implemented which can simultaneously support two or more groups.
2.4
As described in [DSFIELD], a PHB is selected at a node by a mapping
of the DS codepoint in a received packet. Standardized PHBs have a
recommended codepoint. However, the total space of codepoints is
larger than the space available for recommended codepoints for
standardized PHBs, and [DSFIELD] leaves provisions for locally
configurable mappings. A codepoint->PHB mapping table may have
contain both 1->1 and N->1 mappings. All codepoints must be mapped
to some PHB; in the absence of some local policy, codepoints which
are not mapped to a standardized PHB in accordance with that PHB's
specification should be mapped to the Default PHB.
2.5 Network Resource Allocation
The implementation, configuration, operation and administration of
the supported PHB groups in the nodes of a DS Domain should
effectively partition the resources of those nodes and the inter-node
links between the traffic behavior aggregates, in accordance with the domain's
service provisioning policy. Traffic conditioners can further
control the usage of these resources through the administrative control enforcement of TCAs and
Black, et. al. Expires: November 1998 [Page 15]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
possibly through operational feedback from the nodes and traffic
conditioners in the domain. Although a range of services can be
deployed in the absence of complex traffic conditioning functions
(e.g., using only static marking policies), functions such as
policing, shaping, and dynamic re-marking enable the deployment of
services providing quantitative performance metrics.
The configuration of and interaction between the traffic conditioners
and the interior nodes should be managed by the administrative control of
the domain and may require operational control through protocols and
a control entity. There is a wide range of possible control models
[DSFWK]. The precise nature and implementation of the interaction
between these components is outside the scope of this architecture.
However, scalability requires that the control of the domain does not
require micro-management of the network resources. The most scalable
control model would operate nodes in open-loop in the operational
timeframe, and would only require administrative-
timescale administrative-timescale management
as SLAs are varied. This simple model may be unsuitable in some
circumstances, and some automated but relatively
long time-constant slowly varying operational
control (minutes rather than seconds) may be desirable to balance the
utilization of the network against the recent load profile.
Blake, et. al. Expires: February 1999 [Page 19]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
3. Per-Hop Behavior Definition Requirements
In order for a Per Hop Behavior (PHB) group to be considered Specification Guidelines
Basic requirements for
standardization, a detailed definition of the per-hop behavior should be
provided as a basis for implementation consistency. standardization are given in
[DSFIELD]. This section
provides a template elaborates on that text by describing
additional guidelines for defining a new PHB group. (group) specifications. This is
intended to help foster implementation consistency. Before a PHB
group is considered proposed for standardization it should satisfy the PHB
definition requirements in this section, these
guidelines, as appropriate, to preserve the integrity of this
architecture.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to
G.1: A PHB standard must specify a recommended DS codepoint selected
from the codepoint space reserved for standard mappings [DSFIELD].
Recommended codepoints will be interpreted as described in [RFC2119].
3.1. assigned by the IANA. A PHB definition MUST NOT proposal
may recommend a temporary codepoint from the EXP/LU space to
facilitate inter-domain experimentation. Determination of a packet's
PHB must not require inspection or modification of
any part of the additional packet other than header fields
beyond the DS field.
3.2.
G.2: The definition specification of each newly proposed PHB group MUST should
include an overview of the behavior and the purpose of the behavior
being proposed. The overview MUST should include a problem or problems
statement for which the PHB group is targeted. The overview MUST should
include the basic concepts behind the PHB group. These concepts SHOULD
should include, but are not restricted to, queueing behavior, discard
behavior, and output link selection behavior. Lastly, the overview MUST
should specify the method by which the PHB group solves the problem
or problems specified in the problem statement.
Any configuration or management issues which affect the basic PHB
definition MUST should be specified in the overview of the behavior. The
actual details of the management and configuration of PHB groups in
routers or hosts MUST
DS nodes should be addressed in a separate, parallel document.
Black, et. al. Expires: November 1998 [Page 16]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
3.3.
G.3: A PHB group definition MUST specification should indicate whether a PHB group
consists the number of one or more codepoints.
individual PHBs specified. In the event that multiple
codepoints PHBs are
specified, the interactions between the codepoints
within the PHB group these PHBs and constraints that
must be respected globally
across by all the codepoints PHBs within the PHB group MUST should be
clearly
explained in the description of the PHB group. specified. As an example, the
definition MUST specify specification must indicate
whether the probability of packet reordering within a microflow
with is
increased if different packets in that microflow are marked by two or more codepoints for
different PHBs within the group is
likely.
3.4. group.
G.4: A PHB group may be standardized specified for local use within a domain in
order to provide some domain specific domain-specific functionality or domain domain-
specific services. In this event, the PHB definition specification is useful
for providing vendors with a consistent definition of the PHB group.
The PHB definition specification can also provide semantics for PHB translation
and service mappings with between peer domains domains, one of which do does not
support the this PHB group. However, any PHB group which is defined as for
local use MUST should not be considered for standardization, but may be
published as an informational standard. Informational RFC. In contrast, a PHB group which is proposed
intended for general use will follow a stricter standardization
Blake, et. al. Expires: February 1999 [Page 20]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
process. Therefore all proposed PHB definitions MUST proposals should specifically state
whether they are to be considered for general use or local use.
It is recognized that PHB groups can be designed with the intent of
providing host-to-host, WAN edge-to-WAN edge, or domain edge-to-
domain edge services. Use of the term "end-to-end" in a PHB
definition MUST should be interpreted to mean "host-to-host". "host-to-host" for
consistency.
Other PHB groups may be defined and deployed locally within domains,
for experimental or operational purposes. There is no requirement
that these PHB groups must be publically publicly documented, but they SHOULD should
utilize DS codepoints from one of the EXP/LU pools as defined in
[DSFIELD].
3.5.
G.5: It may be possible or appropriate for a packet marked with for a
codepoint
PHB within a PHB group to be re-marked to select another codepoint
within that group PHB; either
within a domain or across two cooperating
domains. a domain boundary. Typically there are three
four reasons for PHB group mutability:
1. modification:
a. The codepoints of associated with the PHB group are collectively
intended to carry state about the network.
2. Changes in the network state network,
b. Conditions which require PHB promotion or demotion of traffic marked with a codepoint packet
(this assumes that PHBs within the PHB group.
3. group can be ranked in some
order),
c. A PHB group is not implemented one on both sides of a domain
boundary; All boundary between
cooperating domains; all codepoints of associated with a PHB group
have to be mapped to some other PHB or PHB set of codepoints selecting PHBs
from another group at in the boundary. next domain,
d. The boundary between two domains is not covered by a SLA. In this
case the codepoint/PHB to select when crossing the boundary link
will be determined by the local policy of the upstream domain.
In contrast, it may also be necessary desirable for specific PHB groups to be
preserved within a domain and/or across multiple domains. Typically
this is because the PHB groups carry some host-to-host, WAN edge-to-
WAN edge, or domain edge-to-domain edge semantics which are difficult
to duplicate when the PHB group is mapped to a different PHB group.
Black, et. al. Expires: November 1998 [Page 17]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
Further, these semantics may also be difficult to duplicate if packet
markings
packets are promoted or demoted within the same PHB group.
A PHB definition MUST specification should clearly state whether the circumstances under
which packets marked by for a
codepoint PHB within a PHB group MAY, may, or SHOULD should be promoted, demoted (to
modified (e.g., promoted or demoted) to another codepoint PHB within the group), group,
or preserved within a domain. A PHB definition MUST specification should clearly
state whether the circumstances under which packets marked by for a
codepoint PHB within a
PHB group MAY, may, or SHOULD should be promoted, demoted, mapped, modified, or preserved across
multiple, cooperating domains when an SLA covering the traffic exists
among the domains. Recommendations for multi-domain treatment of
PHBs do not apply to traffic not covered by a SLA among the domains
involved. A PHB definition
MUST specification should clearly state whether codepoints within the circumstances
under which packets marked for a PHB group MAY, may, or
SHOULD should be mapped to a different marked
Blake, et. al. Expires: February 1999 [Page 21]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
for an alternative PHB group.
If it is desirable undesirable for the packet's PHB (within a PHB group group) to be changed,
modified, the definition
SHOULD specification should clearly state the circumstances under which consequent risks
when the PHB is modified. A possible risk to changing a change packet's
PHB, either within or outside a PHB group, is
desirable. If a higher probability of
packet re-ordering. For certain PHB groups, it is undesirable for may be appropriate to
reflect a state change in the node by changing a PHB. If a PHB group
is designed to be changed, reflect the
definition MUST clearly state what the risks are when of a network, the PHB group is
modified. definition
must adequately describe the relationship between the PHBs and the
states they reflect. A PHB definition specification may include constraints on
actions that change the PHB group. These constraints may be
specified as actions the router SHOULD, node should, or MUST must perform.
3.6. The
G.6: A PHB definition MUST also group specification should include a section defining the
implications of tunneling on the utility of the PHB group. This
section should specify the implications on for the utility of the PHB
group of a newly created outer header when the original PHB group DS field of
the inner header is encapsulated in a tunnel. This section should
also discuss what possible changes should be applied to the inner
header at the egress of the tunnel, when both the PHB groups codepoints from the
inner header and the outer header are accessible.
3.7. accessible (see Sec. 6.2).
G.7: The process of defining specifying PHB groups is likely to be
incremental in nature. When new PHB groups are defined, proposed, their known
interactions with previously defined specified PHB groups MUST should be
documented. When a new PHB group is created, it can be entirely new
in scope or it can be an extension to an existing PHB group. If the
PHB group is entirely independent of some or all of the existing PHB definitions,
specifications, a section
MUST should be included in the PHB definition specification
which details how the new PHB group co-exists can co-exist with those PHB
groups already defined. standardized. For example, this section might
indicate the possibility of packet re-ordering within a microflow with for
packets marked by codepoints within associated with two separate PHB groups.
If concurrent operation of two (or more) different PHB groups in the
same router node is impossible or detrimental this MUST should be stated. If the
concurrent operation of two (or more) different PHB groups requires
some specific behaviors by the router node when traffic specifying packets marked for PHBs from
these different PHB groups are in being processed by the router node at the
same time, these behaviors MUST should be stated.
Care should be taken to avoid circularity in the definitions of PHB
groups.
If the proposed PHB group is an extension to an existing PHB group, a
section MUST should be included in the PHB group definition specification which
details how this extension inter-operates interoperates with the behavior being
extended. Further, if the extension alters or more narrowly defines
the existing behavior in some way, this MUST should also be clearly specified in
the
indicated.
G.8: Each PHB definition.
Black, specification should include a section specifying
Blake, et. al. Expires: November 1998 February 1999 [Page 18] 22]
INTERNET-DRAFT An Architecture for Differentiated Services May August 1998
3.8. Each PHB definition MUST include a section specifying
minimal conformance to requirements for implementations of the PHB
group. This conformance section is intended to provide a means for
specifying the details of a behavior while allowing for
implementation variation to the extent permitted by the PHB definition.
specification. This conformance section can take the form of rules,
tables, pseudo-code pseudo-code, or tests.
3.9.
G.9: A PHB definition MUST specification should include a section detailing the
security implications of the behavior. This section should include a
discussion of the mutability re-marking of the inner header's PHB group codepoint at the
egress of a tunnel. tunnel and its effect on the desired forwarding behavior.
Further, this section should also discuss how the proposed PHB group
could be used in denial-of-service attacks, reduction of service
contract attacks, and service contract violation attacks. Lastly,
this section should discuss possible means for detecting such attacks
as they are relevant to the proposed behavior.
G.10: It is strongly recommended that an appendix be provided for
each PHB specification that considers the implications of the
proposed behavior on current and potential services. These services
could include but are not restricted to be user-specific, device-
specific, domain-specific or end-to-end services. It is also
strongly recommended that the appendix include a section describing
how the services are verified by users, devices, and/or domains.
G.11: If the PHB specification is targeted for local use within a
domain, it is recommended that the appendix include a description of
how the PHB group is best mapped to existing general-use PHB groups
as well as other local-use PHB groups when necessary.
G.12: It is recommended that an appendix be provided with each PHB
specification which considers the means impact of the proposed PHB group on
existing higher-layer protocols. Under some circumstances PHBs
may allow for detecting
such attacks as they are relevant possible changes to higher-layer protocols which may
increase or decrease the utility of the proposed behavior.
3.10. PHB group.
G.13: It is strongly RECOMMENDED recommended that an appendix be provided for with each PHB definition that considers
specification which recommends mappings to link-layer QoS mechanisms
to support the implications intended behavior of the proposed
behavior PHB across a shared-medium or
switched link-layer. The determination of the most appropriate
mapping between a PHB and a link-layer QoS mechanism is dependent on current
many factors and potential services. These services could
include but are not restricted is outside the scope of this document; however, the
specification should attempt to be user specific, device specific,
domain specific offer some guidance.
4. Interoperability with Non-Differentiated Services-Compliant Nodes
We define a non-differentiated services-compliant node (non-DS-compliant
node) as any node which does not interpret the DS field as specified
in [DSFIELD] and/or does not implement some or end all of the
standardized PHBs. This may be due to end services. It is also strongly
RECOMMENDED that the appendix include capabilities or
configuration of the node. We define a section describing how legacy node as a special case
Blake, et. al. Expires: February 1999 [Page 23]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
of a non-DS-compliant node which implements IPv4 Precedence
classification and forwarding as defined in [RFC791, RFC1812], but
which is otherwise not DS compliant. The precedence values in the
services IPv4
TOS octet are verified compatible by users, devices, and/or domains.
3.11. If intention with the Class Selector
Codepoints defined in [DSFIELD], and the precedence forwarding
behaviors defined in [RFC791, RFC1812] comply with the Class Selector
PHB definition is targeted for local use within Requirements also defined in [DSFIELD]. A key distinction
between a
domain, it legacy node and a DS-compliant node is RECOMMENDED that the appendix include a description legacy node
may or may not interpret bits 3-6 of
how the PHB group is mapped to existing general use PHB groups TOS octet as
well defined in
[RFC1349] (the "DTRC" bits); in practice it will not interpret these
bit as other local use PHB groups.
3.12. It is RECOMMENDED specified in [DSFIELD]. We assume that an appendix be provided for each PHB
definition which considers the impact use of the proposed new PHB groups
on existing higher-layer protocols. Under some circumstances PHB
definitions may allow for possible changes to higher-layer protocols TOS
markings defined in [RFC1349] is deprecated. Nodes which are non-DS-
compliant and which are not legacy nodes may increase or decrease exhibit unpredictable
forwarding behaviors for packets with non-zero DS codepoints.
Differentiated services depend on the utility resource allocation mechanisms
provided by per-hop behavior implementations in nodes. The quality
or statistical assurance level of a service may break down in the proposed PHB group.
4. Interoperability with Non-Differentiated Services-Compliant Nodes
event that traffic transits a non-DS-compliant node, or a non-DS-
capable domain.
We define will examine two separate cases. The first case concerns the use
of non-DS-compliant nodes within a non-differentiated services-capable DS domain. Note that PHB forwarding
is primarily useful for allocating scarce node (non-DS-capable
node) as and link resources in
a controlled manner. On high-speed, lightly loaded links, the worst-
case packet delay, jitter, and loss may be negligible, and the use of
a non-DS-compliant node which does on the upstream end of such a link may not interpret
result in service degradation. In more realistic circumstances, the DS field as specified
lack of PHB forwarding in
[DSFIELD] and/or does not implement some a node may make it impossible to offer low-
delay, low-loss, or all of provisioned bandwidth services across paths which
traverse the standardized
PHBs. This node. However, use of a legacy node may be due an
acceptable alternative, assuming that the DS domain restricts itself
to using only the capabilities or configuration of Class Selector Codepoints defined in [DSFIELD], and
assuming that the
node. We distinguish such a particular precedence implementation in the legacy
node from a one which does not implement
differentiated provides forwarding behaviors which can be selected by are compatible with the
value of
services offered along paths which traverse that node. Note that it
is important to restrict the IPv4 TOS byte or codepoints in use to the IPv6 Traffic Class byte. We define
a Selector
Codepoints, since the legacy node as one which implements IPv4 Precedence as defined may or may not interpret bits 3-5
in
[RFC791], but which is otherwise non-DS capable.
Differentiated services depend on accordance with [RFC1349], thereby resulting in unpredictable
forwarding results.
The second case concerns the resource allocation mechanisms
provided by per-hop behavior implementations on nodes. The quality
or statistical assurance level of services which traverse non-
DS-capable domains. We assume for the sake of argument that a service may break down non-
DS-capable domain does not deploy traffic conditioning functions on
domain boundary nodes; therefore, even in the event that the domain
consists of legacy or DS-compliant interior nodes, the lack of traffic
enforcement at the boundaries will limit the ability to consistently
deliver some types of services across the domain. A DS domain and a
non-DS-capable domain may negotiate an agreement which governs how
egress traffic from the DS-domain should be marked before entry into
the non-DS-capable domain. This agreement might be monitored for
compliance by traffic sampling instead of by rigorous traffic transits a non-DS-capable node, or a non-DS-
Black,
Blake, et. al. Expires: November 1998 February 1999 [Page 19] 24]
INTERNET-DRAFT An Architecture for Differentiated Services May August 1998
capable domain.
We will examine two separate cases. The first case concerns
conditioning. Alternatively, where there is knowledge that the use non-
DS-capable domain consists of non-DS-capable nodes within a legacy nodes, the upstream DS domain. Note that PHB forwarding domain
may opportunistically re-mark differentiated services traffic to one
or more of the Class Selector Codepoints. Where there is primarily useful for allocating scarce node no
knowledge of the traffic management capabilities of the downstream
domain, and link resources no agreement in place, a controlled manner. On high-speed, lightly loaded links, the worst-
case packet delay, jitter, and loss DS domain egress node may be negligible, and choose
to re-mark DS codepoints to zero, under the use of assumption that the non-
DS-capable domain will treat the traffic uniformly with best-effort
service.
In the event that a non-DS-capable domain peers with a DS domain,
traffic flowing from the non-DS-capable domain should be conditioned
at the DS ingress node on of the upstream end DS domain according to the appropriate
SLA or policy.
5. Multicast Considerations
Use of such differentiated services by multicast traffic introduces a link may not
result in few
issues for service degradation. In more realistic circumstances, the
lack of PHB forwarding in provisioning. First, multicast packets which
enter a DS domain at an ingress node may make simultaneously take multiple
paths through some segments of the domain due to multicast packet
replication. In this way they consume more network resources than
unicast packets. Where multicast group membership is dynamic, it impossible is
difficult to offer low-
delay, low-loss, or provisioned bandwidth services across paths which
traverse predict in advance the node. However, use amount of a legacy node network resources that
may be consumed by multicast traffic originating from an
acceptable alternative, assuming upstream
network for a particular group. A consequence of this uncertainty is
that the DS domain restricts itself it may be difficult to using only the precedence-compatible PHBs defined in [Baker], provide quantitative service guarantees
to multicast senders. Further, it may be necessary to reserve
codepoints and
assuming that the particular precedence implementation results in
forwarding behaviors which are compatible with the services offered
along paths which traverse that node. PHBs for exclusive use by unicast traffic, to provide
resource isolation from multicast traffic.
The second case concerns issue is the behavior selection of services which traverse non-
DS-capable domains. We assume for the sake of argument that DS codepoint for a non-
DS-capable domain does not deploy traffic conditioning functions on
domain edge nodes; therefore, even in the event multicast
packet arriving at a DS ingress node. Because that packet may exit
the DS domain
consists of legacy or DS-capable interior nodes, the lack of traffic
enforcement at the edges will limit the ability to consistently
deliver some types of services across the domain. A multiple DS domain and a
non-DS-capable domain may negotiate an agreement which governs how egress traffic from nodes which peer with multiple
downstream domains, the DS-domain DS codepoint used should be marked before entry into not result in the non-DS-capable domain. This agreement might be monitored
request for
compliance by a service from a downstream DS domain which is in
violation of a peering SLA. When establishing classifier and traffic sampling instead
conditioner state at an DS ingress node for an aggregate of by rigorous traffic
conditioning. Alternatively, where there is knowledge that
receiving a differentiated service which spans across the egress
boundary of the non-
DS-capable domain consists domain, the identity of legacy nodes, the upstream DS adjacent downstream
transit domain
may opportunistically re-mark differentiated services traffic and the specifics of the corresponding peering SLA can
be factored into the configuration decision (subject to one
or more IPv4 precedence values. Where there is no knowledge routing
policy and the stability of the
traffic management capabilities routing infrastructure). In this way
peering SLAs with downstream DS domains can be partially enforced at
the ingress of the upstream domain, reducing the classification and no agreement in
place, a DS domain
traffic conditioning burden at the egress node may choose to re-mark of the DS field upstream
domain. This is not so easily performed in the case of multicast
traffic, due to
zero, under the assumption possibility of dynamic group membership. The
result is that the non-DS-capable domain will treat
the service guarantees for unicast traffic uniformly with best-effort service.
In the event that may be
impacted. One means of addressing this problem is to establish a non-DS-capable peers with
separate peering SLA for multicast traffic, and to either utilize a DS domain, traffic
flowing from the non-DS-capable domain should be conditioned at the
DS ingress node
Blake, et. al. Expires: February 1999 [Page 25]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
particular set of codepoints for multicast packets, or to implement
the necessary classification and traffic conditioning mechanisms in
the DS domain according egress nodes to provide preferential isolation for unicast
traffic in conformance with the appropriate peering SLA or
policy.
5. Multicast Considerations
For future study. with the downstream
domain.
6. Security and Tunneling Considerations
This section addresses security issues raised by the introduction of
Black, et. al. Expires: November 1998 [Page 20]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
differentiated services, primarily the potential for denial-of-
service attacks, and the related potential for theft of service by
unauthorized traffic (Section (Sec. 6.1). In addition, the operation of
differentiated services in the presence of IPsec and its interaction
with IPsec are also discussed (Section (Sec. 6.2), as well as auditing
requirements (Section (Sec. 6.3). This section considers issues introduced by
the use of both IPsec and non-IPsec tunnels.
6.1 Theft and Denial of Service
The primary goal of differentiated services is to allow different
levels of service to be provided for traffic streams on a common
network infrastructure. A variety of resource management techniques
may be used to achieve this, but the end result will be that some
packets receive different (e.g., better) service than others. The
mapping of network traffic to the specific behaviors that result in
different (e.g., better or worse) service is indicated primarily by
the DS field, and hence an adversary may be able to obtain better
service by modifying the DS field to values codepoints indicating behaviors
used for enhanced services or by injecting packets with the DS field's field
set to such values. codepoints. Taken to its limits, this theft of service
becomes a denial-of-service attack when the modified or injected
traffic depletes the resources available to forward it and other
traffic streams. The defense against such theft- and denial-of-service denial-of-
service attacks consists of a the combination of edge policing and traffic conditioning
at DS boundary nodes along with security and integrity of the network
infrastructure within a DS domain.
As described in Section 2.1, Sec. 2.2, DS ingress nodes must ensure that condition all traffic
entering a DS domain to ensure that it has acceptable DS field values codepoints.
This means that are acceptable the codepoints must conform to that the applicable traffic
conditioning agreement(s) and the domain's service provision provisioning
policy. This makes Hence, the ingress nodes are the first primary line of defense
against theft-of-service theft- and denial-
of-service denial-of-service attacks based on modified DS field values
codepoints (e.g., values codepoints to which the traffic is not entitled). entitled),
as success of any such attack constitutes a violation of the
applicable TCA(s) and/or SPP. An important instance of an ingress
node is that any traffic-originating node in a DS domain is the
ingress node for that traffic, and must ensure that that all originated
traffic carries acceptable DS field values.
A codepoints.
Blake, et. al. Expires: February 1999 [Page 26]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
Both a domain's service provision provisioning policy and traffic conditioning
agreements may require the ingress nodes to change the DS field values codepoint
on some entering packets (e.g., an ingress router may set the DS field values
codepoint of a customer's traffic in accordance with the appropriate
SLA). Ingress nodes should police must condition all other inbound traffic to
ensure that the DS field values codepoints are acceptable; packets found to have
unacceptable values codepoints must either be discarded or must have their
DS fields codepoints modified to acceptable values before being forwarded.
For example, an ingress node receiving traffic from a domain with
which no enhanced service agreement exists may reset the DS field codepoint
to DE(fault) service the Default PHB codepoint [DSFIELD]. A service
provisioning policy may require traffic Traffic authentication may
be required to validate the use of some DS field values codepoints (e.g., those
corresponding to enhanced services), and such authentication may be
performed by technical means (e.g., IPsec) and/or non-technical means
(e.g., the
Black, et. al. Expires: November 1998 [Page 21]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998 inbound link is known to be connected to exactly one
customer site).
An inter-domain agreement may reduce or eliminate the need for
ingress node traffic policing conditioning by making the upstream domain
partly or completely responsible for ensuring that traffic has DS field values
codepoints acceptable to the downstream domain. In this case, the
ingress node may still perform redundant acceptability traffic conditioning checks
to reduce the dependence on the upstream domain (e.g., such checks
can prevent theft-of-service attacks from propagating across the
domain boundary). If an acceptability such a check fails because the upstream domain
is not fulfilling its responsibilities, that failure is an auditable
event; the generated audit log entry should include the date/time the
packet was received, the source and destination IP addresses, and the
DS field value codepoint that caused the failure. In practice, the limited gains
from such checks need to be weighed against their potential
performance impact in determining what, if any, checks to perform
under these circumstances.
Interior nodes in a DS domain may rely on the DS field to associate
differentiated services traffic with the behaviors used to implement
enhanced services. Any node doing so depends on the correct
operation of the DS domain to prevent the arrival of traffic with
unacceptable DS field values. codepoints. Robustness concerns dictate that the
arrival of packets with unacceptable DS field values codepoints must not cause the
failure (e.g., crash) of network nodes. Interior nodes are not
responsible for enforcing the service provisioning policy (or
individual SLAs) and hence are not required to check DS field values
for acceptability. codepoints
before using them. Interior nodes may perform some acceptability traffic
conditioning checks on DS field values codepoints (e.g., check for DS field values codepoints
that are never used for traffic on a specific link, never used with a source/
destination address outside a specific range, etc.) link) to improve
security and robustness (e.g., resistance to theft of service theft-of-service attacks
based on DS field codepoint modifications). Any detected failure of such an
acceptability a
check is an auditable event and the generated audit log entry should
include the date/time the packet was received, the source and
destination IP addresses, and the DS field value codepoint that caused the
failure. In practice, the limited gains from such checks need to be
weighed against their potential performance impact in determining
Blake, et. al. Expires: February 1999 [Page 27]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
what, if any, checks to perform at interior nodes.
Any link that cannot be adequately secured against modification of DS
field values
codepoints or traffic injection by adversaries should be treated as a
boundary link (and hence any arriving traffic on that link is treated
as if it were entering the domain at an ingress node). Local
security policy provides the definition of "adequately secured," and
such a definition may include a determination that the risks and
consequences of DS field codepoint modification and/or traffic injection do
not justify any additional security measures for a link. Link
security can be enhanced via physical access controls and/or software
means such as tunnels that ensure packet integrity.
Black, et. al. Expires: November 1998 [Page 22]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
6.2 IPsec and Tunneling interactions Interactions
The IPsec protocol, as defined in [ESP, AH], does not include the IP
header's DS field in any of its cryptographic calculations (in the
case of tunnel mode, it is the outer IP header's DS field that is not
included). Hence modification of the DS field by a network node has
no effect on IPsec's end-to-end security, because it cannot cause any
IPsec integrity check to fail. As a consequence, IPsec does not
provide any defense against an adversary's modification of the DS
field (i.e., a man-in-the-middle attack); attack), as the adversary's
modification will also have no effect on IPsec's end-to-end security.
In some environments, the ability to modify the DS field without
affecting IPsec integrity checks may constitute a covert channel; if
it is necessary to eliminate such a channel or reduce its bandwidth,
the DS domains should be configured so that the required processing
(e.g., set all DS fields on sensitive traffic to a single value) can
be performed at DS egress nodes where traffic exits higher security
domains.
IPsec's tunnel mode provides security for the encapsulated IP
header's DS field. A tunnel mode IPsec packet contains two IP
headers: an outer header supplied by the tunnel ingress node and an
encapsulated inner header supplied by the original source of the
packet. When an IPsec tunnel is hosted (in whole or in part) on a
differentiated services network, the intermediate network nodes
operate on the DS field in the outer header. At the tunnel egress
node, IPsec processing includes stripping the outer header and
forwarding the packet (if required) using the inner header. Since If the
inner IP header has not been processed by a DS ingress node, node for the
tunnel egress node's DS domain, the tunnel egress node is the DS
ingress node for traffic exiting the tunnel, and hence must carry out
the corresponding traffic conditioning responsibilities (see Section Sec.
6.1). If the IPsec processing includes a sufficiently strong
cryptographic integrity check of the encapsulated packet (where
sufficiency is determined by local security policy), the tunnel
egress node can safely assume that the DS field in the inner header
has the same value as it had at the tunnel ingress node. If
the This allows
a tunnel ingress egress node is in the same DS domain as the tunnel egress
node, the tunnel egress node can ingress
Blake, et. al. Expires: February 1999 [Page 28]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
node, to safely treat a packet passing such an integrity check as if
it had arrived from another node within the same DS domain and hence omit domain, omitting
the DS ingress node policing traffic conditioning that would otherwise be
required. An important consequence is that otherwise insecure internal links within
internal to a DS domains domain can be secured by a sufficiently strong IPsec
tunnel.
This analysis and its implications apply to any tunneling protocol
that performs integrity checks, but the level of assurance of the
inner header's DS field depends on the strength of the integrity
check performed by the tunneling protocol. In the absence of
sufficient assurance for a tunnel that may transit nodes outside the
current DS domain (or is otherwise vulnerable), the encapsulated
packet must be treated as if it had arrived at a DS ingress node from
outside the domain.
Black, et. al. Expires: November 1998 [Page 23]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
The IPsec protocol currently specifies requires that the inner header's DS
field must not be changed by IPsec decapsulation processing at the a tunnel
egress node. This ensures that an adversary's modifications to the
DS field cannot be used to launch theft- or denial-of-service attacks
across an IPsec tunnel endpoint, as any such modifications will be
discarded at the tunnel endpoint.
Note: the following paragraph requires coordination with and approval
by he Security Area of This document makes no change to
that IPsec requirement.
If the IETF, and may result IPsec specifications are modified in the need for brief
modifications of the appropriate security RFCs.
A future to permit a
tunnel egress node in a DS domain may to modify the DS field in an inner IP header based
on the DS field value in the outer header,
including header (e.g., copying part or all
of the outer DS field to the inner DS
field. field), then additional
considerations would apply. For a tunnel contained entirely within a
single DS domain and for which the links are adequately secured
against modifications of the outer DS field, the only limits on inner
DS field modifications are would be those imposed by the domain's service
provisioning policy. Otherwise, the tunnel egress node performing
such modifications is would be acting as a DS ingress node for traffic
exiting the tunnel, tunnel and must carry out the traffic conditioning
responsibilities of an ingress node, including ensuring that the
resulting DS field values are acceptable (see Section defense against theft-
and denial-of-service attacks (See Sec. 6.1). If the tunnel enters
the DS domain at a node different from the tunnel egress node, the
tunnel egress node may depend on the upstream DS ingress node having
ensured the acceptability of that the outer DS field value. values are acceptable. Even in this
case, there are some acceptability checks that can only be performed by the tunnel
egress node (e.g., a consistency check between the inner and outer DS field values
codepoints for an encrypted tunnel). Any detected failure of such a
check is an auditable event and the generated audit log entry should
include the date/time the packet was received, packet was received, the source and
destination IP addresses, and the DS codepoint that was unacceptable.
An IPsec tunnel can be viewed in at least two different ways from an
architectural perspective. If the tunnel is viewed as a logical
single hop "virtual wire", the actions of intermediate nodes in
forwarding the tunneled traffic should not be visible beyond the ends
of the tunnel and hence the DS field should not be modified as part
Blake, et. al. Expires: February 1999 [Page 29]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
of decapsulation processing. In contrast, if the tunnel is viewed as
a multi-hop participant in forwarding traffic, then modification of
the DS field as part of tunnel decapsulation processing may be
desirable. A specific example of the latter situation occurs when a
tunnel terminates at an interior node of a DS domain at which the
domain administrator does not wish to deploy traffic conditioning
logic (e.g., to simplify traffic management). This could be
supported by using the DS codepoint in the source and destination outer IP
addresses, and header (which was
subject to traffic conditioning at the DS field value that was unacceptable. The
requirements in this paragraph apply ingress node) to any future use of reset the
currently unused (CU) bits
DS codepoint in the IPv4 TOS byte and inner IP header, effectively moving DS ingress
traffic conditioning responsibilities from the IPv6 Traffic
Class byte [DSFIELD]. IPsec tunnel egress
node to the appropriate upstream DS ingress node (which must already
perform that function for unencapsulated traffic).
6.3 Auditing
Not all systems that support differentiated services will implement
auditing. However, if differentiated services support is
incorporated into a system that supports auditing, then the
differentiated services implementation must should also support auditing and auditing.
If such support is present the implementation must allow a system
administrator to enable or disable auditing for differentiated services.
services as a whole, and may allow such auditing to be enabled or
disabled in part.
For the most part, the granularity of auditing is a local matter.
However, several auditable events are identified in this document and
for each of these events a minimum set of information that should be
included in an audit log is defined. Additional information also (e.g.,
packets related to the one that triggered the auditable event) may
also be included in the audit log for each of these events, and
additional events, not explicitly called out in this specification,
also may result in audit log
Black, et. al. Expires: November 1998 [Page 24]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998 entries. There is no requirement for
the receiver to transmit any message to the purported sender in
response to the detection of an auditable event, because of the
potential to induce denial of service via such action.
7. Acknowledgements
The authors would like to acknowledge the following individuals for
their helpful comments and suggestions: Kathleen Nichols, Brian
Carpenter, Konstantinos Dovrolis, Shivkumar Kalyana, Wu-chang Feng,
Marty Borden, Yoram Bernet, Ronald Bonica, James Binder, and Borje
Ohlman.
Ohlman, Alessio Casati, Scott Brim, Curtis Villamizar, Brahi, Andrew
Smith, John Renwick, Werner Almesberger, Alan O'Neill, and James Fu.
Blake, et. al. Expires: February 1999 [Page 30]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
8. References
[802.1p] ISO/IEC Final CD 15802-3 Information technology - Tele-
communications and information exchange between systems -
Local and metropolitan area networks - Common
specifications - Part 3: Media Access Control (MAC)
bridges, (current draft available as IEEE P802.1D/D15).
[AH] S. Kent and R. Atkinson, "IP Authentication Header",
Internet Draft <draft-ietf-ipsec-auth-header-06.txt>,
May <draft-ietf-ipsec-auth-header-07.txt>,
July 1998.
[ATM] ATM Traffic Management Specification Version 4.0
<af-tm-0056.000>, April 1996.
[Baker]
[Bernet] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, S. Brim, T. Li, F. Kastenholz, S. Jagannath, L. Zhang,
K. Nichols, and J. Renwick, "IP Precedence in Differentiated
Services Using the Assured Service", M. Speer, "A Framework for Use of
RSVP with Diff-serv Networks", Internet Draft
<draft-ietf-diffserv-precedence-00.txt>, April
<draft-ietf-diffserv-rsvp-00.txt>, June 1998.
[DSFIELD] K. Nichols and Nichols, S. Blake, F. Baker, and D. Black, "Definition
of the Differentiated Services Field (DS Byte) Field) in the
IPv4 and IPv6 Headers", Internet Draft
<draft-ietf-diffserv-header-00.txt>, May
<draft-ietf-diffserv-header-02.txt>, August 1998.
[DSFWK] Differentiated Services Y. Bernet, J. Binder, S. Blake, M. Carlson, E. Davies, B.
Ohlman, D. Verma, Z. Wang, and W. Weiss, "A Framework Document (work in
preparation).
[Clark97] for
Differentiated Services", Internet Draft
<draft-ietf-diffserv-framework-00.txt>, May 1998.
[EXPLICIT] D. Clark and J. Wroclawski, "An Approach to Service W. Fang, "Explicit Allocation in the Internet", Internet Draft
<draft-clark-diff-svc-alloc-00.txt>, July 1997. of Best
Effort Packet Delivery Service", IEEE/ACM Trans. on
Networking, vol. 6, no. 4, August 1998, pp. 362-373.
[Ellesson] E. Ellesson and S. Blake, "A Proposal for the Format and
Semantics of the TOS Byte and Traffic Class Byte in IPv4
and IPv6", Internet Draft <draft-ellesson-tos-00.txt>,
November 1997.
Black, et. al. Expires: November 1998 [Page 25]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
[ESP] S. Kent and R. Atkinson, "IP Encapsulating Security
Payload", Internet Draft
<draft-ietf-ipsec-esp-v2-05.txt>, May
<draft-ietf-ipsec-esp-v2-06.txt>, July 1998.
[Ferguson] P. Ferguson, "Simple Differential Services: IP TOS and
Precedence, Delay Indication, and Drop Preference,
Internet Draft <draft-ferguson-delay-drop-02.txt>,
April 1998.
[FRELAY] ANSI T1S1, "DSSI Core Aspects of Frame Rely", March 1990.
Blake, et. al. Expires: February 1999 [Page 31]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
[Heinanen] J. Heinanen, "Use of the IPv4 TOS Octet to Support
Differentiated Services", Internet Draft
<draft-heinanen-diff-tos-octet-01.txt>, November 1997.
[IntServ] R. Braden, D. Clark, and S. Shenker, "Integrated Services
in the Internet Architecture: An Overview", Internet RFC
1633, July 1994.
[MPLSFWK] R. Callon, P. Doolan, N. Feldman, A. Fredette, G.
Swallow, and A. Viswanathan, "A Framework for
Multiprotocol Label Switching", Internet Draft
<draft-ietf-mpls-framework-02.txt>, November 1997.
[PASTE]
[MPLSTE] D. Awduche, D. H. Gan, T. Li Li, G. Swallow, and Y. Rekhter, "Provider Architecture V.
Srinivasan, "Extensions to RSVP for
Differentiated Services and Traffic Engineering (PASTE)", Engineering",
Internet Draft <draft-li-paste-00.txt>, January <draft-swallow-mpls-rsvp-trafeng-00.txt>,
August 1998.
[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.
[RFC2119]
[RFC1633] R. Braden, D. Clark, and S. Bradner, "Key words for use Shenker, "Integrated Services
in RFCs to Indicate
Requirement Levels", the Internet Architecture: An Overview", Internet RFC 2119, March 1997.
1633, July 1994.
[RFC1812] F. Baker, editor, "Requirements for IP Version 4
Routers", Internet RFC 1812, June 1995.
[RSVP] B. Braden et. al., "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification", Internet RFC
2205, September 1997.
[SIMA] K. Kilkki, "Simple Integrated Media Access (SIMA)",
Internet Draft <draft-kalevi-simple-media-access-01.txt>,
June 1997.
[2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
Differentiated Services Architecture for the Internet",
Internet Draft <draft-nichols-diff-svc-arch-00.txt>,
ftp://ftp.ee.lbl.gov/papers/dsarch.pdf, November 1997.
[TR] ISO/IEC 8802-5 Information technology -
Telecommunications and information exchange between
Black, et. al. Expires: November 1998 [Page 26]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
systems - Local and metropolitan area networks - Common
specifications - Part 5: Token Ring Access Method and
Physical Layer Specifications, (also ANSI/IEEE Std 802.5-
1995), 1995.
[Weiss] W. Weiss, "Providing Differentiated Services Through
Cooperative Dropping and Delay Indication", Internet
Draft <draft-weiss-cooperative-drop-00.txt>, March 1998.
Blake, et. al. Expires: February 1999 [Page 32]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
Authors' Addresses
Steven Blake
Torrent Networking Technologies
2221 Broadbirch Drive
Silver Spring, MD 20904
Phone: +1-301-625-1600
E-mail: slblake@torrentnet.com
David Black
The Open Group Research Institute
Eleven
11 Cambridge Center
Cambridge, MA 02142
Phone: +1-617-621-7347
E-mail: d.black@opengroup.org
Steven Blake
IBM Corporation
800 Park Offices Drive
Research Triangle Park, NC 27709
Phone: +1-919-254-2030
E-mail: slblake@raleigh.ibm.com
Mark A. Carlson
Redcape Software,
Sun Microsystems, Inc.
2990 Center Green Court South
Boulder, CO 80301
Phone: +1-303-448-0048 x115
E-mail: mac@redcape.com mark.carlson@sun.com
Elwyn Davies
Nortel UK
London Road
Harlow, Essex CM17 9NA, UK
Phone: +44-1279-405498
E-mail: elwynd@nortel.co.uk
Zheng Wang
Bell Labs Lucent Tech Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733
E-mail: zhwang@bell-labs.com
Walter Weiss
Lucent Technologies
300 Baker Avenue, Suite 100,
Concord, MA 01742-2168
E-mail: wweiss@lucent.com
Black,
Blake, et. al. Expires: November February 1999 [Page 33]
INTERNET-DRAFT An Architecture for Differentiated Services August 1998
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Blake, et. al. Expires: February 1999 [Page 27] 34]
----