As per Relevance of the word condition, we have this rfc below:
Network Working Group S.
Request for Comments: 2475 Torrent Networking
Category: Informational D.
EMC
M.
Sun
E.
Nortel
Z.
Bell Labs Lucent
W.
Lucent
December 1998
An Architecture for Differentiated
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document defines an architecture for implementing
service differentiation in the Internet. This architecture
scalability by aggregating traffic classification state which
conveyed by means of IP-layer packet marking using the DS
[DSFIELD]. Packets are classified and marked to receive a
per-hop forwarding behavior on nodes along their path.
classification, marking, policing, and shaping operations need
be implemented at network boundaries or hosts. Network resources
allocated to traffic streams by service provisioning policies
govern how traffic is marked and conditioned upon entry to
differentiated services-capable network, and how that traffic
forwarded within that network. A wide variety of services can
implemented on top of these building blocks
Blake, et. al. Informational [Page 1]
RFC 2475 Architecture for Differentiated Services December 1998
Table of
1. Introduction ................................................. 2
1.1 Overview ................................................. 2
1.2 Terminology ............................................... 4
1.3 Requirements .............................................. 8
1.4 Comparisons with Other Approaches ......................... 9
2. Differentiated Services Architectural Model .................. 12
2.1 Differentiated Services Domain ............................ 12
2.1.1 DS Boundary Nodes and Interior Nodes .................. 12
2.1.2 DS Ingress Node and Egress Node ....................... 13
2.2 Differentiated Services Region ............................ 13
2.3 Traffic Classification and Conditioning ................... 14
2.3.1 Classifiers ........................................... 14
2.3.2 Traffic Profiles ...................................... 15
2.3.3 Traffic Conditioners .................................. 15
2.3.3.1 Meters ............................................ 16
2.3.3.2 Markers ........................................... 16
2.3.3.3 Shapers ........................................... 17
2.3.3.4 Droppers .......................................... 17
2.3.4 Location of Traffic Conditioners and MF Classifiers ... 17
2.3.4.1 Within the Source Domain .......................... 17
2.3.4.2 At the Boundary of a DS Domain .................... 18
2.3.4.3 In non-DS-Capable Domains ......................... 18
2.3.4.4 In Interior DS Nodes .............................. 19
2.4 Per-Hop Behaviors ......................................... 19
2.5 Network Resource Allocation ............................... 20
3. Per-Hop Behavior Specification Guidelines .................... 21
4. Interoperability with Non-Differentiated Services-
Nodes ........................................................ 25
5. Multicast Considerations ..................................... 26
6. Security and Tunneling Considerations ........................ 27
6.1 Theft and Denial of Service ............................... 28
6.2 IPsec and Tunneling Interactions .......................... 30
6.3 Auditing .................................................. 32
7. Acknowledgements ............................................. 32
8. References ................................................... 33
Authors' Addresses ............................................... 34
Full Copyright Statement ......................................... 36
1.
1.1
This document defines an architecture for implementing
service differentiation in the Internet. A "Service" defines
significant characteristics of packet transmission in one
across a set of one or more paths within a network.
Blake, et. al. Informational [Page 2]
RFC 2475 Architecture for Differentiated Services December 1998
characteristics may be specified in quantitative or statistical
of throughput, delay, jitter, and/or loss, or may otherwise
specified in terms of some relative priority of access to
resources. Service differentiation is desired to
heterogeneous application requirements and user expectations, and
permit differentiated pricing of Internet service
This architecture is composed of a number of functional
implemented in network nodes, including a small set of per-
forwarding behaviors, packet classification functions, and
conditioning functions including metering, marking, shaping,
policing. This architecture achieves scalability by
complex classification and conditioning functions only at
boundary nodes, and by applying per-hop behaviors to aggregates
traffic which have been appropriately marked using the DS field
the IPv4 or IPv6 headers [DSFIELD]. Per-hop behaviors are defined
permit a reasonably granular means of allocating buffer and
resources at each node among competing traffic streams. Per
application flow or per-customer forwarding state need not
maintained within the core of the network. A distinction
maintained between
o the service provided to a traffic aggregate
o the conditioning functions and per-hop behaviors used to
services
o the DS field value (DS codepoint) used to mark packets to select
per-hop behavior,
o the particular node implementation mechanisms which realize
per-hop behavior
Service provisioning and traffic conditioning policies
sufficiently decoupled from the forwarding behaviors within
network interior to permit implementation of a wide variety
service behaviors, with room for future expansion
This architecture only provides service differentiation in
direction of traffic flow and is therefore asymmetric.
of a complementary symmetric architecture is a topic of
research but is outside the scope of this document; see for
[EXPLICIT].
Sect. 1.2 is a glossary of terms used within this document. Sec. 1.3
lists requirements addressed by this architecture, and Sec. 1.4
provides a brief comparison to other approaches for
differentiation. Sec. 2 discusses the components of the
Blake, et. al. Informational [Page 3]
RFC 2475 Architecture for Differentiated Services December 1998
in detail. Sec. 3 proposes guidelines for per-hop
specifications. Sec. 4 discusses interoperability issues with
and networks which do not implement differentiated services
defined in this document and in [DSFIELD]. Sec. 5 discusses
with multicast service delivery. Sec. 6 addresses security
tunnel considerations
1.2
This section gives a general conceptual overview of the terms used
this document. Some of these terms are more precisely defined
later sections of this document
Behavior Aggregate (BA) a DS behavior aggregate
BA classifier a classifier that selects packets
only on the contents of the DS field
Boundary link a link connecting the edge nodes of
domains
Classifier an entity which selects packets based
the content of packet headers according
defined rules
DS behavior aggregate a collection of packets with the same
codepoint crossing a link in a
direction
DS boundary node a DS node that connects one DS domain to
node either in another DS domain or in
domain that is not DS-capable
DS-capable capable of implementing
services as described in this architecture
usually used in reference to a
consisting of DS-compliant nodes
DS codepoint a specific value of the DSCP portion of
DS field, used to select a PHB
DS-compliant enabled to support differentiated
functions and behaviors as defined
[DSFIELD], this document, and
differentiated services documents;
used in reference to a node or device
Blake, et. al. Informational [Page 4]
RFC 2475 Architecture for Differentiated Services December 1998
DS domain a DS-capable domain; a contiguous set
nodes which operate with a common set
service provisioning policies and
definitions
DS egress node a DS boundary node in its role in
traffic as it leaves a DS domain
DS ingress node a DS boundary node in its role in
traffic as it enters a DS domain
DS interior node a DS node that is not a DS boundary node
DS field the IPv4 header TOS octet or the IPv
Traffic Class octet when interpreted
conformance with the definition given
[DSFIELD]. The bits of the DSCP
encode the DS codepoint, while
remaining bits are currently unused
DS node a DS-compliant node
DS region a set of contiguous DS domains which
offer differentiated services over
across those DS domains
Downstream DS domain the DS domain downstream of traffic flow
a boundary link
Dropper a device that performs dropping
Dropping the process of discarding packets based
specified rules; policing
Legacy node a node which implements IPv4 Precedence
defined in [RFC791,RFC1812] but which
otherwise not DS-compliant
Marker a device that performs marking
Marking the process of setting the DS codepoint
a packet based on defined rules; pre
marking, re-marking
Mechanism a specific algorithm or operation (e.g.,
queueing discipline) that is implemented
a node to realize a set of one or more per
hop behaviors
Blake, et. al. Informational [Page 5]
RFC 2475 Architecture for Differentiated Services December 1998
Meter a device that performs metering
Metering the process of measuring the
properties (e.g., rate) of a traffic
selected by a classifier.
instantaneous state of this process may
used to affect the operation of a marker
shaper, or dropper, and/or may be used
accounting and measurement purposes
Microflow a single instance of an application-to
application flow of packets which
identified by source address, source port
destination address, destination port
protocol id
MF Classifier a multi-field (MF) classifier which
packets based on the content of
arbitrary number of header fields
typically some combination of
address, destination address, DS field
protocol ID, source port and
port
Per-Hop-Behavior (PHB) the externally observable
behavior applied at a DS-compliant node
a DS behavior aggregate
PHB group a set of one or more PHBs that can only
meaningfully specified and
simultaneously, due to a common
applying to all PHBs in the set such as
queue servicing or queue management policy
A PHB group provides a service
block that allows a set of
forwarding behaviors to be
together (e.g., four dropping priorities).
A single PHB is a special case of a
group
Policing the process of discarding packets (by
dropper) within a traffic stream
accordance with the state of
corresponding meter enforcing a
profile
Pre-mark to set the DS codepoint of a packet
to entry into a downstream DS domain
Blake, et. al. Informational [Page 6]
RFC 2475 Architecture for Differentiated Services December 1998
Provider DS domain the DS-capable provider of services to
source domain
Re-mark to change the DS codepoint of a packet
usually performed by a marker in
with a TCA
Service the overall treatment of a defined
of a customer's traffic within a DS
or end-to-end
Service Level Agreement a service contract between a customer and
(SLA) service provider that specifies
forwarding service a customer
receive. A customer may be a
organization (source domain) or another
domain (upstream domain). A SLA
include traffic conditioning rules
constitute a TCA in whole or in part
Service Provisioning a policy which defines how
Policy conditioners are configured on DS
nodes and how traffic streams are mapped
DS behavior aggregates to achieve a
of services
Shaper a device that performs shaping
Shaping the process of delaying packets within
traffic stream to cause it to conform
some defined traffic profile
Source domain a domain which contains the node(s
originating the traffic receiving
particular service
Traffic conditioner an entity which performs
conditioning functions and which
contain meters, markers, droppers,
shapers. Traffic conditioners are
deployed in DS boundary nodes only.
traffic conditioner may re-mark a
stream or may discard or shape packets
alter the temporal characteristics of
stream and bring it into compliance with
traffic profile
Blake, et. al. Informational [Page 7]
RFC 2475 Architecture for Differentiated Services December 1998
Traffic conditioning control functions performed to
rules specified in a TCA,
metering, marking, shaping, and policing
Traffic Conditioning an agreement specifying classifier
Agreement (TCA) and any corresponding traffic profiles
metering, marking, discarding and/
shaping rules which are to apply to
traffic streams selected by the classifier
A TCA encompasses all of the
conditioning rules explicitly
within a SLA along with all of the
implicit from the relevant
requirements and/or from a DS domain'
service provisioning policy
Traffic profile a description of the temporal
of a traffic stream such as rate and
size
Traffic stream an administratively significant set of
or more microflows which traverse a
segment. A traffic stream may consist
the set of active microflows which
selected by a particular classifier
Upstream DS domain the DS domain upstream of traffic flow on
boundary link
1.3
The history of the Internet has been one of continuous growth in
number of hosts, the number and variety of applications, and
capacity of the network infrastructure, and this growth is
to continue for the foreseeable future. A scalable architecture
service differentiation must be able to accommodate this
growth
The following requirements were identified and are addressed in
architecture
o should accommodate a wide variety of services and
policies, extending end-to-end or within a particular (set of
network(s),
o should allow decoupling of the service from the
application in use
Blake, et. al. Informational [Page 8]
RFC 2475 Architecture for Differentiated Services December 1998
o should work with existing applications without the need
application programming interface changes or host
modifications (assuming suitable deployment of classifiers
markers, and other traffic conditioning functions),
o should decouple traffic conditioning and service
functions from forwarding behaviors implemented within the
network nodes
o should not depend on hop-by-hop application signaling
o should require only a small set of forwarding behaviors
implementation complexity does not dominate the cost of a
device, and which will not introduce bottlenecks for future high
speed system implementations
o should avoid per-microflow or per-customer state within
network nodes
o should utilize only aggregated classification state within
network core
o should permit simple packet classification implementations in
network nodes (BA classifier),
o should permit reasonable interoperability with non-DS-
network nodes
o should accommodate incremental deployment
1.4 Comparisons with Other
The differentiated services architecture specified in this
can be contrasted with other existing models of
differentiation. We classify these alternative models into
following categories: relative priority marking, service marking
label switching, Integrated Services/RSVP, and static per-
classification
Examples of the relative priority marking model include IPv
Precedence marking as defined in [RFC791], 802.5 Token Ring
[TR], and the default interpretation of 802.1p traffic
[802.1p]. In this model the application, host, or proxy node
a relative priority or "precedence" for a packet (e.g., delay
discard priority), and the network nodes along the transit path
the appropriate priority forwarding behavior corresponding to
priority value within the packet's header. Our architecture can
considered as a refinement to this model, since we more
Blake, et. al. Informational [Page 9]
RFC 2475 Architecture for Differentiated Services December 1998
specify the role and importance of boundary nodes and
conditioners, and since our per-hop behavior model permits
general forwarding behaviors than relative delay or discard priority
An example of a service marking model is IPv4 TOS as defined
[RFC1349]. In this example each packet is marked with a request
a "type of service", which may include "minimize delay", "
throughput", "maximize reliability", or "minimize cost".
nodes may select routing paths or forwarding behaviors which
suitably engineered to satisfy the service request. This model
subtly different from our architecture. Note that we do not
the use of the DS field as an input to route selection. The
markings defined in [RFC1349] are very generic and do not span
range of possible service semantics. Furthermore, the
request is associated with each individual packet, whereas
service semantics may depend on the aggregate forwarding behavior
a sequence of packets. The service marking model does not
accommodate growth in the number and range of future services (
the codepoint space is small) and involves configuration of
"TOS->forwarding behavior" association in each core network node
Standardizing service markings implies standardizing
offerings, which is outside the scope of the IETF. Note
provisions are made in the allocation of the DS codepoint space
allow for locally significant codepoints which may be used by
provider to support service marking semantics [DSFIELD].
Examples of the label switching (or virtual circuit) model
Frame Relay, ATM, and MPLS [FRELAY, ATM]. In this model
forwarding state and traffic management or QoS state is
for traffic streams on each hop along a network path.
aggregates of varying granularity are associated with a
switched path at an ingress node, and packets/cells within each
switched path are marked with a forwarding label that is used
lookup the next-hop node, the per-hop forwarding behavior, and
replacement label at each hop. This model permits finer
resource allocation to traffic streams, since label values are
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
switching semantics govern the next-hop selection, allowing a
stream to follow a specially engineered path through the network
This improved granularity comes at the cost of additional
and configuration requirements to establish and maintain the
switched paths. In addition, the amount of forwarding
maintained at each node scales in proportion to the number of
nodes of the network in the best case (assuming multipoint-to-
Blake, et. al. Informational [Page 10]
RFC 2475 Architecture for Differentiated Services December 1998
label switched paths), and it scales in proportion with the square
the number of edge nodes in the worst case, when edge-edge
switched paths with provisioned resources are employed
The Integrated Services/RSVP model relies upon traditional
forwarding in the default case, but allows sources and receivers
exchange signaling messages which establish additional
classification and forwarding state on each node along the
between them [RFC1633, RSVP]. In the absence of state aggregation
the amount of state on each node scales in proportion to the
of concurrent reservations, which can be potentially large on high
speed links. This model also requires application support for
RSVP signaling protocol. Differentiated services mechanisms can
utilized to aggregate Integrated Services/RSVP state in the core
the network [Bernet].
A variant of the Integrated Services/RSVP model eliminates
requirement for hop-by-hop signaling by utilizing only "static
classification and forwarding policies which are implemented in
node along a network path. These policies are updated
administrative timescales and not in response to the
mix of microflows active in the network. The state requirements
this variant are potentially worse than those encountered when
is used, especially in backbone nodes, since the number of
policies that might be applicable at a node over time may be
than the number of active sender-receiver sessions that might
installed reservation state on a node. Although the support of
numbers of classifier rules and forwarding policies may
computationally feasible, the management burden associated
installing and maintaining these rules on each node within a
network which might be traversed by a traffic stream is substantial
Although we contrast our architecture with these alternative
of service differentiation, it should be noted that links and
employing these techniques may be utilized to extend
services behaviors and semantics across a layer-2
infrastructure (e.g., 802.1p LANs, Frame Relay/ATM backbones
interconnecting DS nodes, and in the case of MPLS may be used as
alternative intra-domain implementation technology. The
imposed by the use of a specific link-layer technology in
regions of a DS domain (or in a network providing access to
domains) may imply the differentiation of traffic on a coarser
basis. Depending on the mapping of PHBs to different link-
services and the way in which packets are scheduled over a
set of priority classes (or virtual circuits of different
and capacity), all or a subset of the PHBs in use may be
(or may be indistinguishable).
Blake, et. al. Informational [Page 11]
RFC 2475 Architecture for Differentiated Services December 1998
2. Differentiated Services Architectural
The differentiated services architecture is based on a simple
where traffic entering a network is classified and
conditioned at the boundaries of the network, and assigned
different behavior aggregates. Each behavior aggregate is
by a single DS codepoint. Within the core of the network,
are forwarded according to the per-hop behavior associated with
DS codepoint. In this section, we discuss the key components
a differentiated services region, traffic classification
conditioning functions, and how differentiated services are
through the combination of traffic conditioning and PHB-
forwarding
2.1 Differentiated Services
A DS domain is a contiguous set of DS nodes which operate with
common service provisioning policy and set of PHB groups
on each node. A DS domain has a well-defined boundary consisting
DS boundary nodes which classify and possibly condition
traffic to ensure that packets which transit the domain
appropriately marked to select a PHB from one of the PHB
supported within the domain. Nodes within the DS domain select
forwarding behavior for packets based on their DS codepoint,
that value to one of the supported PHBs using either the
codepoint->PHB mapping or a locally customized mapping [DSFIELD].
Inclusion of non-DS-compliant nodes within a DS domain may result
unpredictable performance and may impede the ability to
service level agreements (SLAs).
A DS domain normally consists of one or more networks under the
administration; for example, an organization's intranet or an ISP
The administration of the domain is responsible for ensuring
adequate resources are provisioned and/or reserved to support
SLAs offered by the domain
2.1.1 DS Boundary Nodes and Interior
A DS domain consists of DS boundary nodes and DS interior nodes.
boundary nodes interconnect the DS domain to other DS or non-DS
capable domains, whilst DS interior nodes only connect to other
interior or boundary nodes within the same DS domain
Both DS boundary nodes and interior nodes must be able to apply
appropriate PHB to packets based on the DS codepoint;
unpredictable behavior may result. In addition, DS boundary
may be required to perform traffic conditioning functions as
by a traffic conditioning agreement (TCA) between their DS domain
Blake, et. al. Informational [Page 12]
RFC 2475 Architecture for Differentiated Services December 1998
the peering domain which they connect to (see Sec. 2.3.3).
Interior nodes may be able to perform limited traffic
functions such as DS codepoint re-marking. Interior nodes
implement more complex classification and traffic
functions are analogous to DS boundary nodes (see Sec. 2.3.4.4).
A host in a network containing a DS domain may act as a DS
node for traffic from applications running on that host; we
say that the host is within the DS domain. If a host does not act
a boundary node, then the DS node topologically closest to that
acts as the DS boundary node for that host's traffic
2.1.2 DS Ingress Node and Egress
DS boundary nodes act both as a DS ingress node and as a DS
node for different directions of traffic. Traffic enters a DS
at a DS ingress node and leaves a DS domain at a DS egress node.
DS ingress node is responsible for ensuring that the traffic
the DS domain conforms to any TCA between it and the other domain
which the ingress node is connected. A DS egress node may
traffic conditioning functions on traffic forwarded to a
connected peering domain, depending on the details of the TCA
the two domains. Note that a DS boundary node may act as a
interior node for some set of interfaces
2.2 Differentiated Services
A differentiated services region (DS Region) is a set of one or
contiguous DS domains. DS regions are capable of
differentiated services along paths which span the domains within
region
The DS domains in a DS region may support different PHB
internally and different codepoint->PHB mappings. However, to
services which span across the domains, the peering DS domains
each establish a peering SLA which defines (either explicitly
implicitly) a TCA which specifies how transit traffic from one
domain to another is conditioned at the boundary between the two
domains
It is possible that several DS domains within a DS region may adopt
common service provisioning policy and may support a common set
PHB groups and codepoint mappings, thus eliminating the need
traffic conditioning between those DS domains
Blake, et. al. Informational [Page 13]
RFC 2475 Architecture for Differentiated Services December 1998
2.3 Traffic Classification and
Differentiated services are extended across a DS domain boundary
establishing a SLA between an upstream network and a downstream
domain. The SLA may specify packet classification and re-
rules and may also specify traffic profiles and actions to
streams which are in- or out-of-profile (see Sec. 2.3.2). The
between the domains is derived (explicitly or implicitly) from
SLA
The packet classification policy identifies the subset of
which may receive a differentiated service by being conditioned and
or mapped to one or more behavior aggregates (by DS codepoint re
marking) within the DS domain
Traffic conditioning performs metering, shaping, policing and/or re
marking to ensure that the traffic entering the DS domain conforms
the rules specified in the TCA, in accordance with the domain'
service provisioning policy. The extent of traffic
required is dependent on the specifics of the service offering,
may range from simple codepoint re-marking to complex policing
shaping operations. The details of traffic conditioning
which are negotiated between networks is outside the scope of
document
2.3.1
Packet classifiers select packets in a traffic stream based on
content of some portion of the packet header. We define two types
classifiers. The BA (Behavior Aggregate) Classifier
packets based on the DS codepoint only. The MF (Multi-Field
classifier selects packets based on the value of a combination of
or more header fields, such as source address, destination address
DS field, protocol ID, source port and destination port numbers,
other information such as incoming interface
Classifiers are used to "steer" packets matching some specified
to an element of a traffic conditioner for further processing
Classifiers must be configured by some management procedure
accordance with the appropriate TCA
The classifier should authenticate the information which it uses
classify the packet (see Sec. 6).
Note that in the event of upstream packet fragmentation,
classifiers which examine the contents of transport-layer
fields may incorrectly classify packet fragments subsequent to
first. A possible solution to this problem is to
Blake, et. al. Informational [Page 14]
RFC 2475 Architecture for Differentiated Services December 1998
fragmentation state; however, this is not a general solution due
the possibility of upstream fragment re-ordering or divergent
paths. The policy to apply to packet fragments is outside the
of this document
2.3.2 Traffic
A traffic profile specifies the temporal properties of a
stream selected by a classifier. It provides rules for
whether a particular packet is in-profile or out-of-profile.
example, a profile based on a token bucket may look like
codepoint=X, use token-bucket r,
The above profile indicates that all packets marked with DS
X should be measured against a token bucket meter with rate r
burst size b. In this example out-of-profile packets are
packets in the traffic stream which arrive when insufficient
are available in the bucket. The concept of in- and out-of-
can be extended to more than two levels, e.g., multiple levels
conformance with a profile may be defined and enforced
Different conditioning actions may be applied to the in-
packets and out-of-profile packets, or different accounting
may be triggered. In-profile packets may be allowed to enter the
domain without further conditioning; or, alternatively, their
codepoint may be changed. The latter happens when the DS
is set to a non-Default value for the first time [DSFIELD], or
the packets enter a DS domain that uses a different PHB group
codepoint->PHB mapping policy for this traffic stream. Out-of
profile packets may be queued until they are in-profile (shaped),
discarded (policed), marked with a new codepoint (re-marked),
forwarded unchanged while triggering some accounting procedure
Out-of-profile packets may be mapped to one or more
aggregates that are "inferior" in some dimension of
performance to the BA into which in-profile packets are mapped
Note that a traffic profile is an optional component of a TCA and
use is dependent on the specifics of the service offering and
domain's service provisioning policy
2.3.3 Traffic
A traffic conditioner may contain the following elements: meter
marker, shaper, and dropper. A traffic stream is selected by
classifier, which steers the packets to a logical instance of
traffic conditioner. A meter is used (where appropriate) to
the traffic stream against a traffic profile. The state of the
Blake, et. al. Informational [Page 15]
RFC 2475 Architecture for Differentiated Services December 1998
with respect to a particular packet (e.g., whether it is in- or out
of-profile) may be used to affect a marking, dropping, or
action
When packets exit the traffic conditioner of a DS boundary node
DS codepoint of each packet must be set to an appropriate value
Fig. 1 shows the block diagram of a classifier and
conditioner. Note that a traffic conditioner may not
contain all four elements. For example, in the case where no
profile is in effect, packets may only pass through a classifier
a marker
+-------+
| |-------------------+
+----->| Meter | |
| | |--+ |
| +-------+ | |
| V
+------------+ +--------+ +---------+
| | | | | Shaper/ |
packets =====>| Classifier |=====>| Marker |=====>| Dropper |=====>
| | | | | |
+------------+ +--------+ +---------+
Fig. 1: Logical View of a Packet Classifier and Traffic
2.3.3.1
Traffic meters measure the temporal properties of the stream
packets selected by a classifier against a traffic profile
in a TCA. A meter passes state information to other
functions to trigger a particular action for each packet which
either in- or out-of-profile (to some extent).
2.3.3.2
Packet markers set the DS field of a packet to a
codepoint, adding the marked packet to a particular DS
aggregate. The marker may be configured to mark all packets
are steered to it to a single codepoint, or may be configured to
a packet to one of a set of codepoints used to select a PHB in a
group, according to the state of a meter. When the marker
the codepoint in a packet it is said to have "re-marked" the packet
Blake, et. al. Informational [Page 16]
RFC 2475 Architecture for Differentiated Services December 1998
2.3.3.3
Shapers delay some or all of the packets in a traffic stream in
to bring the stream into compliance with a traffic profile. A
usually has a finite-size buffer, and packets may be discarded
there is not sufficient buffer space to hold the delayed packets
2.3.3.4
Droppers discard some or all of the packets in a traffic stream
order to bring the stream into compliance with a traffic profile
This process is know as "policing" the stream. Note that a
can be implemented as a special case of a shaper by setting
shaper buffer size to zero (or a few) packets
2.3.4 Location of Traffic Conditioners and MF
Traffic conditioners are usually located within DS ingress and
boundary nodes, but may also be located in nodes within the
of a DS domain, or within a non-DS-capable domain
2.3.4.1 Within the Source
We define the source domain as the domain containing the node(s
which originate the traffic receiving a particular service.
sources and intermediate nodes within a source domain may
traffic classification and conditioning functions. The
originating from the source domain across a boundary may be marked
the traffic sources directly or by intermediate nodes before
the source domain. This is referred to as initial marking or "pre
marking".
Consider the example of a company that has the policy that its CEO'
packets should have higher priority. The CEO's host may mark the
field of all outgoing packets with a DS codepoint that
"higher priority". Alternatively, the first-hop router
connected to the CEO's host may classify the traffic and mark
CEO's packets with the correct DS codepoint. Such high
traffic may also be conditioned near the source so that there is
limit on the amount of high priority traffic forwarded from
particular source
There are some advantages to marking packets close to the
source. First, a traffic source can more easily take
application's preferences into account when deciding which
should receive better forwarding treatment. Also, classification
Blake, et. al. Informational [Page 17]
RFC 2475 Architecture for Differentiated Services December 1998
packets is much simpler before the traffic has been aggregated
packets from other sources, since the number of classification
which need to be applied within a single node is reduced
Since packet marking may be distributed across multiple nodes,
source DS domain is responsible for ensuring that the
traffic towards its provider DS domain conforms to the
TCA. Additional allocation mechanisms such as bandwidth brokers
RSVP may be used to dynamically allocate resources for a
DS behavior aggregate within the provider's network [2BIT, Bernet].
The boundary node of the source domain should also
conformance to the TCA, and may police, shape, or re-mark packets
necessary
2.3.4.2 At the Boundary of a DS
Traffic streams may be classified, marked, and otherwise
on either end of a boundary link (the DS egress node of the
domain or the DS ingress node of the downstream domain). The
between the domains should specify which domain has
for mapping traffic streams to DS behavior aggregates
conditioning those aggregates in conformance with the
TCA. However, a DS ingress node must assume that the
traffic may not conform to the TCA and must be prepared to
the TCA in accordance with local policy
When packets are pre-marked and conditioned in the upstream domain
potentially fewer classification and traffic conditioning rules
to be supported in the downstream DS domain. In this
the downstream DS domain may only need to re-mark or police
incoming behavior aggregates to enforce the TCA. However,
sophisticated services which are path- or source-dependent
require MF classification in the downstream DS domain's
nodes
If a DS ingress node is connected to an upstream non-DS-
domain, the DS ingress node must be able to perform all
traffic conditioning functions on the incoming traffic
2.3.4.3 In non-DS-Capable
Traffic sources or intermediate nodes in a non-DS-capable domain
employ traffic conditioners to pre-mark traffic before it reaches
ingress of a downstream DS domain. In this way the local
for classification and marking may be concealed
Blake, et. al. Informational [Page 18]
RFC 2475 Architecture for Differentiated Services December 1998
2.3.4.4 In Interior DS
Although the basic architecture assumes that complex
and traffic conditioning functions are located only in a network'
ingress and egress boundary nodes, deployment of these functions
the interior of the network is not precluded. For example,
restrictive access policies may be enforced on a transoceanic link
requiring MF classification and traffic conditioning functionality
the upstream node on the link. This approach may have
limits, due to the potentially large number of classification
conditioning rules that might need to be maintained
2.4 Per-Hop
A per-hop behavior (PHB) is a description of the
observable forwarding behavior of a DS node applied to a
DS behavior aggregate. "Forwarding behavior" is a general concept
this context. For example, in the event that only one
aggregate occupies a link, the observable forwarding behavior (i.e.,
loss, delay, jitter) will often depend only on the relative
of the link (i.e., in the event that the behavior assumes a work
conserving scheduling discipline). Useful behavioral
are mainly observed when multiple behavior aggregates compete
buffer and bandwidth resources on a node. The PHB is the means
which a node allocates resources to behavior aggregates, and it is
top of this basic hop-by-hop resource allocation mechanism
useful differentiated services may be constructed
The most simple example of a PHB is one which guarantees a
bandwidth allocation of X% of a link (over some reasonable
interval) to a behavior aggregate. This PHB can be fairly
measured under a variety of competing traffic conditions. A
more complex PHB would guarantee a minimal bandwidth allocation of X
of a link, with proportional fair sharing of any excess
capacity. In general, the observable behavior of a PHB may depend
certain constraints on the traffic characteristics of the
behavior aggregate, or the characteristics of other
aggregates
PHBs may be specified in terms of their resource (e.g., buffer
bandwidth) priority relative to other PHBs, or in terms of
relative observable traffic characteristics (e.g., delay, loss).
These PHBs may be used as building blocks to allocate resources
should be specified as a group (PHB group) for consistency.
groups will usually share a common constraint applying to each
within the group, such as a packet scheduling or buffer
policy. The relationship between PHBs in a group may be in terms
absolute or relative priority (e.g., discard priority by means
Blake, et. al. Informational [Page 19]
RFC 2475 Architecture for Differentiated Services December 1998
deterministic or stochastic thresholds), but this is not
(e.g., N equal link shares). A single PHB defined in isolation is
special case of a PHB group
PHBs are implemented in nodes by means of some buffer management
packet scheduling mechanisms. PHBs are defined in terms of
characteristics relevant to service provisioning policies, and not
terms of particular implementation mechanisms. In general, a
of implementation mechanisms may be suitable for implementing
particular PHB group. Furthermore, it is likely that more than
PHB group may be implemented on a node and utilized within a domain
PHB groups should be defined such that the proper resource
between groups can be inferred, and integrated mechanisms can
implemented which can simultaneously support two or more groups.
PHB group definition should indicate possible conflicts
previously documented PHB groups which might prevent
operation
As described in [DSFIELD], a PHB is selected at a node by a
of the DS codepoint in a received packet. Standardized PHBs have
recommended codepoint. However, the total space of codepoints
larger than the space available for recommended codepoints
standardized PHBs, and [DSFIELD] leaves provisions for
configurable mappings. A codepoint->PHB mapping table may
both 1->1 and N->1 mappings. All codepoints must be mapped to
PHB; in the absence of some local policy, codepoints which are
mapped to a standardized PHB in accordance with that PHB'
specification should be mapped to the Default PHB
2.5 Network Resource
The implementation, configuration, operation and administration
the supported PHB groups in the nodes of a DS Domain
effectively partition the resources of those nodes and the inter-
links between behavior aggregates, in accordance with the domain'
service provisioning policy. Traffic conditioners can
control the usage of these resources through enforcement of TCAs
possibly through operational feedback from the nodes and
conditioners in the domain. Although a range of services can
deployed in the absence of complex traffic conditioning
(e.g., using only static marking policies), functions such
policing, shaping, and dynamic re-marking enable the deployment
services providing quantitative performance metrics
The configuration of and interaction between traffic conditioners
interior nodes should be managed by the administrative control of
domain and may require operational control through protocols and
control entity. There is a wide range of possible control models
Blake, et. al. Informational [Page 20]
RFC 2475 Architecture for Differentiated Services December 1998
The precise nature and implementation of the interaction
these components is outside the scope of this architecture. However
scalability requires that the control of the domain does not
micro-management of the network resources. The most scalable
model would operate nodes in open-loop in the operational timeframe
and would only require administrative-timescale management as
are varied. This simple model may be unsuitable in
circumstances, and some automated but slowly varying
control (minutes rather than seconds) may be desirable to balance
utilization of the network against the recent load profile
3. Per-Hop Behavior Specification
Basic requirements for per-hop behavior standardization are given
[DSFIELD]. This section elaborates on that text by
additional guidelines for PHB (group) specifications. This
intended to help foster implementation consistency. Before a
group is proposed for standardization it should satisfy
guidelines, as appropriate, to preserve the integrity of
architecture
G.1: A PHB standard must specify a recommended DS codepoint
from the codepoint space reserved for standard mappings [DSFIELD].
Recommended codepoints will be assigned by the IANA. A PHB
may recommend a temporary codepoint from the EXP/LU space
facilitate inter-domain experimentation. Determination of a packet'
PHB must not require inspection of additional packet header
beyond the DS field
G.2: The specification of each newly proposed PHB group
include an overview of the behavior and the purpose of the
being proposed. The overview should include a problem or
statement for which the PHB group is targeted. The overview
include the basic concepts behind the PHB group. These
should include, but are not restricted to, queueing behavior,
behavior, and output link selection behavior. Lastly, the
should specify the method by which the PHB group solves the
or problems specified in the problem statement
G.3: A PHB group specification should indicate the number
individual PHBs specified. In the event that multiple PHBs
specified, the interactions between these PHBs and constraints
must be respected globally by all the PHBs within the group should
clearly specified. As an example, the specification must
whether the probability of packet reordering within a microflow
increased if different packets in that microflow are marked
different PHBs within the group
Blake, et. al. Informational [Page 21]
RFC 2475 Architecture for Differentiated Services December 1998
G.4: When proper functioning of a PHB group is dependent
constraints such as a provisioning restriction, then the
definition should describe the behavior when these constraints
violated. Further, if actions such as packet discard or re-
are required when these constraints are violated, then these
should be specifically stipulated
G.5: A PHB group may be specified for local use within a domain
order to provide some domain-specific functionality or domain
specific services. In this event, the PHB specification is
for providing vendors with a consistent definition of the PHB group
However, any PHB group which is defined for local use should not
considered for standardization, but may be published as
Informational RFC. In contrast, a PHB group which is intended
general use will follow a stricter standardization process
Therefore all PHB proposals should specifically state whether
are to be considered for general or local use
It is recognized that PHB groups can be designed with the intent
providing host-to-host, WAN edge-to-WAN edge, and/or domain edge-to
domain edge services. Use of the term "end-to-end" in a
definition should be interpreted to mean "host-to-host"
consistency
Other PHB groups may be defined and deployed locally within domains
for experimental or operational purposes. There is no
that these PHB groups must be publicly documented, but they
utilize DS codepoints from one of the EXP/LU pools as defined
[DSFIELD].
G.6: It may be possible or appropriate for a packet marked for a
within a PHB group to be re-marked to select another PHB within
group; either within a domain or across a domain boundary.
there are three reasons for such PHB modification
a. The codepoints associated with the PHB group are
intended to carry state about the network
b. Conditions exist which require PHB promotion or demotion of
packet (this assumes that PHBs within the group can be ranked
some order),
c. The boundary between two domains is not covered by a SLA. In
case the codepoint/PHB to select when crossing the boundary
will be determined by the local policy of the upstream domain
A PHB specification should clearly state the circumstances
which packets marked for a PHB within a PHB group may, or should
modified (e.g., promoted or demoted) to another PHB within the group
If it is undesirable for a packet's PHB to be modified,
Blake, et. al. Informational [Page 22]
RFC 2475 Architecture for Differentiated Services December 1998
specification should clearly state the consequent risks when the
is modified. A possible risk to changing a packet's PHB,
within or outside a PHB group, is a higher probability of packet re
ordering within a microflow. PHBs within a group may carry
host-to-host, WAN edge-to-WAN edge, and/or domain edge-to-domain
semantics which may be difficult to duplicate if packets are re
marked to select another PHB from the group (or otherwise).
For certain PHB groups, it may be appropriate to reflect a
change in the node by re-marking packets to specify another PHB
within the group. If a PHB group is designed to reflect the state
a network, the PHB definition must adequately describe
relationship between the PHBs and the states they reflect. Further
if these PHBs limit the forwarding actions a node can perform in
way, these constraints may be specified as actions the node should
or must perform
G.7: A PHB group specification should include a section defining
implications of tunneling on the utility of the PHB group.
section should specify the implications for the utility of the
group of a newly created outer header when the original DS field
the inner header is encapsulated in a tunnel. This section
also discuss what possible changes should be applied to the
header at the egress of the tunnel, when both the codepoints from
inner header and the outer header are accessible (see Sec. 6.2).
G.8: The process of specifying PHB groups is likely to
incremental in nature. When new PHB groups are proposed, their
interactions with previously specified PHB groups should
documented. When a new PHB group is created, it can be entirely
in scope or it can be an extension to an existing PHB group. If
PHB group is entirely independent of some or all of the existing
specifications, a section should be included in the PHB
which details how the new PHB group can co-exist with those
groups already standardized. For example, this section
indicate the possibility of packet re-ordering within a microflow
packets marked by codepoints associated with two separate PHB groups
If concurrent operation of two (or more) different PHB groups in
same node is impossible or detrimental this should be stated. If
concurrent operation of two (or more) different PHB groups
some specific behaviors by the node when packets marked for PHBs
these different PHB groups are being processed by the node at
same time, these behaviors should be stated
Care should be taken to avoid circularity in the definitions of
groups
Blake, et. al. Informational [Page 23]
RFC 2475 Architecture for Differentiated Services December 1998
If the proposed PHB group is an extension to an existing PHB group,
section should be included in the PHB group specification
details how this extension interoperates with the behavior
extended. Further, if the extension alters or more narrowly
the existing behavior in some way, this should also be
indicated
G.9: Each PHB specification should include a section
minimal conformance requirements for implementations of the
group. This conformance section is intended to provide a means
specifying the details of a behavior while allowing
implementation variation to the extent permitted by the
specification. This conformance section can take the form of rules
tables, pseudo-code, or tests
G.10: A PHB specification should include a section detailing
security implications of the behavior. This section should include
discussion of the re-marking of the inner header's codepoint at
egress of a tunnel and its effect on the desired forwarding behavior
Further, this section should also discuss how the proposed PHB
could be used in denial-of-service attacks, reduction of
contract attacks, and service contract violation attacks. Lastly
this section should discuss possible means for detecting such
as they are relevant to the proposed behavior
G.11: A PHB specification should include a section
configuration and management issues which may affect the operation
the PHB and which may impact candidate services that might
the PHB
G.12: It is strongly recommended that an appendix be provided
each PHB specification that considers the implications of
proposed behavior on current and potential services. These
could include but are not restricted to be user-specific, device
specific, domain-specific or end-to-end services. It is
strongly recommended that the appendix include a section
how the services are verified by users, devices, and/or domains
G.13: It is recommended that an appendix be provided with each
specification that is targeted for local use within a domain
providing guidance for PHB selection for packets which are
into a peer domain which does not support the PHB group
Blake, et. al. Informational [Page 24]
RFC 2475 Architecture for Differentiated Services December 1998
G.14: It is recommended that an appendix be provided with each
specification which considers the impact of the proposed PHB group
existing higher-layer protocols. Under some circumstances PHBs
allow for possible changes to higher-layer protocols which
increase or decrease the utility of the proposed PHB group
G.15: It is recommended that an appendix be provided with each
specification which recommends mappings to link-layer QoS
to support the intended behavior of the PHB across a shared-medium
switched link-layer. The determination of the most
mapping between a PHB and a link-layer QoS mechanism is dependent
many factors and is outside the scope of this document; however,
specification should attempt to offer some guidance
4. Interoperability with Non-Differentiated Services-Compliant
We define a non-differentiated services-compliant node (non-DS
compliant node) as any node which does not interpret the DS field
specified in [DSFIELD] and/or does not implement some or all of
standardized PHBs (or those in use within a particular DS domain).
This may be due to the capabilities or configuration of the node.
define a legacy node as a special case of a non-DS-compliant
