INTERNET-DRAFT David Black
Diffserv Working Group The Open Group
Expires: November 1998 Steven Blake
IBM Corporation
Mark Carlson
Redcape Software
Elwyn Davies
Nortel UK
Zheng Wang
Bell Labs Lucent Technologies
Walter Weiss
Lucent Technologies
May 1998
An Architecture for Differentiated Services
<draft-ietf-diffserv-arch-00.txt>
Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
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 along their path.
Sophisticated classification, policing, and shaping operations need
only be implemented at network boundaries or hosts. Network
resources are allocated to traffic streams by service provisioning
policies which govern how traffic is 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
implemented on top of these building blocks.
This document should be read along with its companion documents, the
the differentiated services framework [DSFWK], the definition of the
DS field [DSFIELD], and other documents which specify per-hop
behaviors, such as [Baker].
1. Introduction
1.1 Overview
This document defines an architecture for implementing scalable
service differentiation in the Internet. "Service" is taken to
signify some significant characteristics of packet transmission
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, and traffic conditioning functions
including classification, metering, marking, shaping, and policing.
This architecture achieves scalability by implementing complex
conditioning functions only at network edge 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 among
competing traffic streams. Per-application flow or per-customer
forwarding state need not be maintained within the core of the
network. Service provisioning and traffic conditioning policies are
sufficiently decoupled from the forwarding behaviors within the
network interior to permit a wide variety of service behaviors to be
implemented, with room for future expansion.
Section 1.2 is a glossary of terms used within this document.
Section 1.3 lists requirements for this architecture, and Section 1.4
provides a brief comparison to other approaches for service
differentiation. Section 2 discusses the components of the
architecture in detail. Section 3 proposes requirements for per-hop
behavior specifications. Section 4 discusses interoperability issues
with networks which do not implement differentiated services as
defined in this document and [DSFIELD]. Section 5 discusses issues
with multicast traffic (this section is currently left for future
study). Section 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]. It has been heavily influenced by the thoughtful
proposals of previous authors [Clark97, Ellesson, 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.
Boundary a link connecting the edge nodes of two
domains.
Classifier a logical element of traffic conditioning
that selects packets based on the content
of packet headers according to defined
rules.
Customer DS domain a DS domain that has an SLA in place 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 DS
domain. A single DS domain may be both a
customer DS domain and a provider DS domain
for different directions of traffic at the
same time.
Differentiated Services a paradigm for providing quality-of-service
(DS) (QoS) 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 that have the same DS
codepoint.
DS field the IPv4 TOS octet or IPv6 Traffic Class
octet when interpreted according to
[DSFIELD].
Black, et. al. Expires: November 1998 [Page 3]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
DS capable able 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 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.
DS domain a contiguous set of nodes which operate
with a common set of service provisioning
policies and PHB definitions.
DS host a host computer that can perform certain
traffic conditioning functions and
therefore acts as a special DS edge node.
DS ingress node a DS edge 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 node.
DS node a DS capable node.
DS region a set of contiguous DS domains which can
offer differentiated services over paths
across those DS domains.
DS source host a DS host that acts as a DS ingress node.
Legacy node a node which implements IPv4 Precedence as
defined in [RFC791] but which is otherwise
not DS capable.
Marker a logical element of traffic conditioning
that sets the DS codepoint in the DS field
based on defined rules.
MF Classifier a classifier which selects packets 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, et. al. Expires: November 1998 [Page 4]
INTERNET-DRAFT An Architecture for Differentiated Services May 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
that measures the properties (e.g., rate)
of a packet stream selected by a
classifier.
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.
Per-Hop-Behavior (PHB) the externally observable forwarding
behavior applied at a DS capable 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 or discard policy.
Policing the process of applying traffic
conditioning functions such as marking or
discarding to a traffic stream in
accordance with the state of a
corresponding meter.
Provider DS domain a DS domain that has an SLA in place with
another directly attached DS domain (the
customer DS domain) governing the rules by
which traffic from the customer DS domain
will be serviced within the provider DS
domain. A single DS domain may be both a
customer DS domain and a provider DS domain
for different directions of traffic at the
same time.
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 service
behavior a customer should receive. A
customer may be a user organization or
another DS domain.
Black, et. al. Expires: November 1998 [Page 5]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
Service Provisioning a policy which defines how traffic
Policy conditioners are configured on DS edge
nodes and how traffic streams are mapped to
DS behavior aggregates to achieve a range
of service behaviors.
Shaper a logical element of traffic conditioning
that delays packets within a traffic stream
to cause it to conform to some defined
traffic properties.
Traffic conditioner an entity that performs traffic
conditioning and which may contain
classifiers, markers, meters, and shapers.
Traffic conditioning control functions performed to enforce
rules specified in a TCA and to prepare
traffic for differentiated services,
including classifying, metering, marking,
policing, and shaping.
Traffic Conditioning an agreement specifying classifier rules
Agreement (TCA) and the corresponding traffic profiles and
metering, marking, policing and/or shaping
rules which are to apply to the traffic
streams selected by the classifier.
Traffic profile a description of the expected 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.
1.3 Requirements
The history of the Internet has been 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 accommodate a wide variety of service behaviors 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 allow decoupling of the service behavior from the particular
application in use,
o must work with existing applications (assuming suitable deployment
of traffic conditioners),
o must decouple traffic conditioning and service provisioning
functions from forwarding behaviors implemented within the core
network routers,
o must not depend on hop-by-hop application signaling,
o must 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 future high-
speed system implementations,
o must avoid per-microflow or per-customer state within core network
routers,
o must utilize only aggregated classification state within the
network core,
o must permit simple packet classification implementations in core
network routers (BA classifier),
o must permit reasonable interoperability with non-compliant network
nodes,
o must 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,
Integrated Services/RSVP, and service marking.
Implementations of the relative priority model include IPv4
Precedence marking as defined in [RFC791], 802.5 Token Ring priority
[TR], and 802.1p priority [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 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 of the virtual circuit model include Frame Relay,
ATM, and MPLS [FRELAY, ATM, PASTE]. 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 each virtual circuit are marked with a forwarding label that
is used to lookup the next hop, the per-hop forwarding behavior, and
the replacement label at each hop. This model permits finer
granularity resource allocation to traffic streams, but the amount
of forwarding state scales linearly with the number of edges of the
network in the best case (assuming multipoint-to-point virtual
circuits), and it scales with the square of the number of edges in
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 with each individual
packet, whereas some service semantics may depend on the aggregate
forwarding behavior of a sequence of packets. The service marking
model does not easily accommodate growth in the number and range of
future services, 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 is conditioned at the edges of the
network, and assigned to different behavior aggregates. Each
behavior aggregate is identified with 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 a differentiated services region,
traffic 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 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.
A DS domain has a well-defined boundary consisting of DS edge nodes
which condition ingress traffic and ensure that packets which transit
the domain are only marked using one of the PHB groups supported in
the domain. All nodes inside the DS domain select the forwarding
behavior for packets based solely on the DS codepoint as defined for
the PHB groups supported in the domain. Inclusion of non-DS capable
nodes within a DS domain may result in unpredictable performance and
may impede the ability to satisfy SLAs.
A DS domain normally consists of one or more networks under the same
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 DS Edge Nodes and Interior Nodes
A DS domain consists of DS edge nodes and DS interior nodes. While
DS edge nodes connect the DS domain to other DS or non-DS domains, DS
interior nodes only connect to other DS interior or edge nodes within
the DS domain.
Both DS edge nodes and interior nodes must be able to forward packets
based on the DS codepoint as defined by the PHB groups supported in
the domain; 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 nodes must be able to perform traffic conditioning functions
as described by the TCA between their DS domain and the peering
domain which they connect to.
Interior nodes may be able to perform limited traffic conditioning
functions such as DS codepoint mutation.
A host within a DS domain may act as a DS edge node for traffic to
and from applications running on that host. If a host is embedded in
a DS domain and does not act as an edge node, then the host's first-
hop router acts as the DS edge node for the host's traffic.
2.1.3 DS Ingress Node and Egress Node
DS edge nodes may act both as a DS ingress node or as a DS egress
node. 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 TCA
between it and the other domain which the ingress node is connected
to. A DS egress node may perform traffic conditioning functions on
traffic forwarded to the peering domain, depending on the details of
the TCA between two domains.
2.2 Traffic Conditioning
Traffic conditioning functions are performed by DS edge nodes in a DS
domain to ensure that the traffic entering a 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. The classifier and the meter select the
packets within a traffic stream and measure the stream against a
traffic profile. The marker and shaper perform control actions on
the packets depending on whether the traffic stream is within its
associated profile.
A packet stream normally passes to a classifier first, and the
matched packets are measured by a meter against the profile as
defined in the TCA. The packets within the profile may leave the
traffic conditioner or may be marked by the marker. The packets that
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 the traffic conditioner of a DS ingress node, the DS
field of each packet must be set to one of DS codepoints defined by
the PHB groups supported in the DS domain.
Black, et. al. Expires: November 1998 [Page 10]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
Fig. 1 shows the block diagram of a traffic conditioner. Note that a
traffic conditioner may not necessarily contain all four elements.
For example, packets may pass from the classifier directly to the
marker or shaper (null meter).
+-------+
-->| |---->
+-------+ +-------+ / +-------+
| | | |/ marker
packets -----> | |------>| |-------------------->
| | | |\
+-------+ +-------+ \ +-------+
classifier meter -->| |---->
+-------+
shaper
Fig. 1: Logical View of a Traffic Conditioner
2.2.2 Traffic Conditioning Agreement (TCA)
Differentiated services are extended across a DS domain boundary by
establishing a SLA between the customer and provider DS domains. The
SLA includes a traffic conditioning agreement which usually specifies
traffic profiles and actions to in-profile and out-of-profile
packets.
2.2.2.1 Traffic Profiles
A traffic profile specifies rules for classifying and measuring a
traffic stream. It identifies what packets are eligible and rules
for determining whether a particular packet is in-profile or out-of-
profile. For example, a profile based on token bucket may look like:
codepoint=X, use token-bucket r, b
The above profile indicates that all packets in the behavior
aggregate 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 packets are those packets in the behavior aggregate which
arrive when insufficient tokens are available in the bucket.
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; or, alternatively,
their DS field may be marked with a new DS codepoint. The latter
Black, et. al. Expires: November 1998 [Page 11]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
happens when the DS field 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 for this traffic stream, so the DS codepoint has
to be mapped to the new PHB group.
The actions to out-of-profile packets may include delaying 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 of a Traffic Conditioner
2.2.3.1 Classifiers
Packet classifiers select packets in a traffic stream based on the
content of some portion of the packet header. The classification 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 packets matching some specified rule to another element of the
traffic conditioner for further processing. Classifiers must be
configured by some management procedure in accordance with the
appropriate TCA.
The classifier should authenticate the information which it uses to
classify the packet (see Sec. 6).
Note that in the event of upstream packet fragmentation, multi-field
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 general solution due to
the possibility of upstream fragment re-ordering or divergent routing
paths.
2.2.3.2 Meters
Traffic meters measure the traffic properties of the set of packets
selected by a classifier against a traffic profile specified in the
TCA. A meter indicates to other conditioning functions whether each
individual packet is 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 Markers
Packet markers set the DS field of a packet to a particular
codepoint, adding the marked packet to a particular DS behavior
Black, et. al. Expires: November 1998 [Page 12]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
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 a PHB group according
to the state of a meter.
2.2.3.4 Shapers
Shapers delay some or all of the packets in a traffic stream in order
to bring the stream into compliance with its associated traffic
profile. A shaper usually has a finite-size buffer, and packets may
be discarded if there is not enough buffer space to hold the delayed
packets. Note that discard policers 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 Location of Traffic Conditioners
Traffic conditioners may be located within a customer DS domain, and
at the boundary of a DS domain. Traffic conditioners may also be
located in nodes in a non-DS domain.
2.2.4.1 Traffic Conditioners within a Customer DS Domain
Traffic sources and nodes within a customer DS domain may perform
traffic conditioning functions. The packets originating from the
customer DS domain across a boundary may have their DS field marked
by the traffic sources or by intermediate routers before leaving the
customer DS domain.
For example, suppose that a customer domain has a policy that the
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. 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.
There are some advantages to marking the DS field close to the
traffic source. First, a traffic source can more easily take an
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 nodes, the
customer 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. The edge node of
the customer DS domain should also monitor conformance to the TCA,
and triage 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 the Boundary of a DS Domain
Traffic streams may be marked and otherwise conditioned on either end
of a boundary link (the DS egress node of the customer DS domain or
the DS ingress node of the provider DS 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
in the customer DS domain since it is then no longer necessary to
divulge the local classification and service provisioning rules to
the provider DS domain. In this circumstance the provider domain may
only need to re-mark or police incoming behavior aggregates to
enforce the TCA. However, more sophisticated services which are
path- or source-dependent may require multi-field classification in
the provider's ingress nodes.
Since packet marking may be distributed across different nodes, the
If a DS ingress node is connected to a non-DS domain, the DS ingress
node must be able to perform all traffic conditioning functions on
the incoming traffic.
2.2.4.3 Traffic Conditioners in non-DS Domains
Traffic sources or intermediate nodes in a non-DS domain may employ
traffic conditioners to pre-mark traffic before it reaches the
ingress of a provider DS domain.
2.3 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 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 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]. These PHBs should be specified as a group (PHB group) for
consistency. The priority relationship within a PHB group will tend
to be hierarchical, and the associated DS codepoints should be
assigned in increasing order of relative priority for clarity of
interpretation. The priority relationship between PHBs in the group
may be absolute (e.g., absolute discard priority) or may be less
rigid (e.g., higher probability of loss). A single PHB defined in
isolation is a degenerate form of a PHB group.
PHBs are implemented in nodes by means of some buffer management and
packet scheduling mechanisms. PHBs should be defined in terms of
behavior characteristics relevant to service provisioning policies,
and not in 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 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 aggregates, in accordance with the domain's
service provisioning policy. Traffic conditioners control the usage
of these resources through the administrative control 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.
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 management as SLAs are varied. This simple model may be
unsuitable in some circumstances, and some automated but relatively
long time-constant operational control (minutes rather than seconds)
may be desirable to balance the utilization of the network against
the recent load profile.
3. Per-Hop Behavior Definition Requirements
In order for a Per Hop Behavior (PHB) group to be considered for
standardization, a detailed definition of the behavior should be
provided as a basis for implementation consistency. This section
provides a template for defining a new PHB group. Before a PHB group
is considered for standardization it should satisfy the PHB
definition requirements in this section, 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 be interpreted as described in [RFC2119].
3.1. A PHB definition MUST NOT require inspection or modification of
any part of the packet other than the DS field.
3.2. The definition of each newly proposed PHB group MUST include an
overview of the behavior and the purpose of the behavior being
proposed. The overview MUST include a problem or problems statement
for which the PHB group is targeted. The overview MUST include the
basic concepts behind the PHB group. These concepts SHOULD include,
but are not restricted to, queueing behavior, discard behavior, and
output link selection behavior. Lastly, the overview MUST 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 be specified in the overview of the behavior. The
actual details of the management and configuration of PHB groups in
routers or hosts MUST 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. A PHB group definition MUST indicate whether a PHB group
consists of one or more codepoints. In the event that multiple
codepoints are specified, the interactions between the codepoints
within the PHB group and constraints that must be respected globally
across all the codepoints within the PHB group MUST be clearly
explained in the description of the PHB group. As an example, the
definition MUST specify whether packet reordering within a microflow
with packets marked by two or more codepoints within the group is
likely.
3.4. A PHB group may be standardized for local use within a domain
in order to provide some domain specific functionality or domain
specific services. In this event, the PHB definition is useful for
providing vendors with a consistent definition of the PHB group. The
PHB definition can also provide semantics for PHB translation and
service mappings with peer domains which do not support the PHB
group. However, any PHB group which is defined as local use MUST be
considered as an informational standard. In contrast, a PHB group
which is proposed for general use will follow a stricter
standardization process. Therefore all proposed PHB definitions MUST
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 be interpreted to mean "host-to-host".
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 documented, but they SHOULD
utilize DS codepoints from one of the EXP/LU pools as defined in
[DSFIELD].
3.5. It may be possible or appropriate for a packet marked with a
codepoint within a PHB group to be re-marked to another codepoint
within that group either within a domain or across two cooperating
domains. Typically there are three reasons for PHB group mutability:
1. The codepoints of the PHB group are collectively intended to carry
state about the network.
2. Changes in the network state which require promotion or demotion
of traffic marked with a codepoint within the PHB group.
3. A PHB group is not implemented one both sides of a domain
boundary; All codepoints of a PHB group have to be mapped to some
other PHB or PHB group at the boundary.
In contrast, it may also be necessary 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 are promoted or demoted within the same PHB group.
A PHB definition MUST clearly state whether packets marked by a
codepoint within a PHB group MAY, or SHOULD be promoted, demoted (to
another codepoint within the group), or preserved within a domain. A
PHB definition MUST clearly state whether packets marked by a
codepoint within a PHB group MAY, or SHOULD be promoted, demoted, or
preserved across multiple, cooperating domains. A PHB definition
MUST clearly state whether codepoints within a PHB group MAY, or
SHOULD be mapped to a different PHB group.
If it is desirable for a PHB group to be changed, the definition
SHOULD clearly state the circumstances under which a change is
desirable. If it is undesirable for a PHB group to be changed, the
definition MUST clearly state what the risks are when a PHB group is
modified. A PHB definition may include constraints on actions that
change the PHB group. These constraints may be specified as actions
the router SHOULD, or MUST perform.
3.6. The PHB definition MUST also include a section defining the
implications of tunneling on the PHB group. This section should
specify the implications on the PHB group of a newly created outer
header when the original PHB group 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 from the inner header and the
outer header are accessible.
3.7. The process of defining PHB groups is incremental in nature.
When new PHB groups are defined, their known interactions with
previously defined PHB groups MUST 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, a section
MUST be included in the PHB definition which details how the new PHB
group co-exists with those PHB groups already defined. For example,
this section might indicate the possibility of packet re-ordering
within a microflow with packets marked by codepoints within two
separate PHB groups. If concurrent operation of two (or more)
different PHB groups in the same router is impossible or detrimental
this MUST be stated. If the concurrent operation of two (or more)
different PHB groups requires some specific behaviors by the router
when traffic specifying these different PHB groups are in the router
at the same time, these behaviors MUST be stated.
If the proposed PHB group is an extension to an existing PHB group, a
section MUST be included in the PHB group definition which details
how this extension inter-operates with the behavior being extended.
Further, if the extension alters or more narrowly defines the
existing behavior in some way, this MUST also be clearly specified in
the PHB definition.
Black, et. al. Expires: November 1998 [Page 18]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
3.8. Each PHB definition MUST include a section specifying minimal
conformance to 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. This conformance section can take the form of rules,
tables, pseudo-code or tests.
3.9. A PHB definition MUST include a section detailing the security
implications of the behavior. This section should include a
discussion of the mutability of the inner header's PHB group at the
egress of a tunnel. 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 the means for detecting
such attacks as they are relevant to the proposed behavior.
3.10. It is strongly RECOMMENDED that an appendix be provided for
each PHB definition 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.
3.11. If the PHB definition is targeted for local use within a
domain, it is RECOMMENDED that the appendix include a description of
how the PHB group is mapped to existing general use PHB groups as
well as other local use PHB groups.
3.12. It is RECOMMENDED that an appendix be provided for each PHB
definition which considers the impact 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
which may increase or decrease the utility of the proposed PHB group.
4. Interoperability with Non-Differentiated Services-Compliant Nodes
We define a non-differentiated services-capable node (non-DS-capable
node) as a node which does not interpret the DS field as specified in
[DSFIELD] and/or does not implement some or all of the standardized
PHBs. This may be due to the capabilities or configuration of the
node. We distinguish such a node from a one which does not implement
differentiated forwarding behaviors which can be selected by the
value of the IPv4 TOS byte or the IPv6 Traffic Class byte. We define
a legacy node as one which implements IPv4 Precedence as defined in
[RFC791], but which is otherwise non-DS capable.
Differentiated services depend on the resource allocation mechanisms
provided by per-hop behavior implementations on nodes. The quality
or statistical assurance level of a service may break down in the
event that traffic transits a non-DS-capable node, or a non-DS-
Black, et. al. Expires: November 1998 [Page 19]
INTERNET-DRAFT An Architecture for Differentiated Services May 1998
capable domain.
We will examine two separate cases. The first case concerns the use
of non-DS-capable nodes within a DS domain. Note that PHB forwarding
is primarily useful for allocating scarce node 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-capable node on the upstream end of such a link may not
result in service degradation. In more realistic circumstances, the
lack of PHB forwarding in a node may make it impossible to offer low-
delay, low-loss, or provisioned bandwidth services across paths which
traverse the node. However, use of a legacy node may be an
acceptable alternative, assuming that the DS domain restricts itself
to using only the precedence-compatible PHBs defined in [Baker], and
assuming that the particular precedence implementation results in
forwarding behaviors which are compatible with the services offered
along paths which traverse that node.
The second case concerns the behavior of services which traverse non-
DS-capable domains. We assume for the sake of argument that a non-
DS-capable domain does not deploy traffic conditioning functions on
domain edge nodes; therefore, even in the event that the 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 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
conditioning. Alternatively, where there is knowledge that the non-
DS-capable domain consists of legacy nodes, the upstream DS domain
may opportunistically re-mark differentiated services traffic to one
or more IPv4 precedence values. Where there is no knowledge of the
traffic management capabilities of the domain, and no agreement in
place, a DS domain egress node may choose to re-mark the DS field to
zero, under the assumption that the non-DS-capable domain will treat
the traffic uniformly with best-effort service.
In the event that a non-DS-capable peers with a DS domain, traffic
flowing from the non-DS-capable domain should be conditioned at the
DS ingress node of the DS domain according to the appropriate SLA or
policy.
5. Multicast Considerations
For future study.
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 6.1). In addition, the operation of
differentiated services in the presence of IPsec and its interaction
with IPsec are also discussed (Section 6.2), as well as auditing
requirements (Section 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 indicating behaviors used
for enhanced services or by injecting packets with DS field's set to
such values. 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
attacks consists of a combination of edge policing and security of
the network infrastructure within a DS domain.
As described in Section 2.1, DS ingress nodes must ensure that all
traffic entering a DS domain has DS field values that are acceptable
to that domain's service provision policy. This makes the ingress
nodes the first line of defense against theft-of-service and denial-
of-service attacks based on modified DS field values (e.g., values to
which the traffic is not entitled). 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 traffic
carries acceptable DS field values.
A domain's service provision policy may require the ingress nodes to
change the DS field values on some entering packets (e.g., an ingress
router may set the DS field values of a customer's traffic in
accordance with the appropriate SLA). Ingress nodes should police
all other inbound traffic to ensure that the DS field values are
acceptable; packets found to have unacceptable values must either be
discarded or must have their DS fields 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 to DE(fault) service [DSFIELD]. A service
provisioning policy may require traffic authentication to validate
the use of some DS field values (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 by making the upstream domain partly or
completely responsible for ensuring that traffic has DS field values
acceptable to the downstream domain. In this case, the ingress node
may still perform redundant acceptability 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 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 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. Robustness concerns dictate that the
arrival of packets with unacceptable DS field values 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. Interior nodes may perform some acceptability
checks on DS field values (e.g., check for DS field values that are
never used for traffic on a specific link, never used with a source/
destination address outside a specific range, etc.) to improve
security and robustness (e.g., resistance to theft of service attacks
based on DS field modifications). Any detected failure of such an
acceptability 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 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 at interior nodes.
Any link that cannot be adequately secured against modification of DS
field values 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 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
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); 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 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
the inner IP header has not been processed by a DS ingress node, the
tunnel egress node is the DS ingress node for traffic exiting the
tunnel, and hence must carry out the corresponding responsibilities
(see Section 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 tunnel ingress node is in the same DS domain as the tunnel egress
node, the tunnel egress node can 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 the DS ingress node policing that would
otherwise be required. An important consequence is that otherwise
insecure internal links within DS domains 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
IPsec currently specifies that the inner header's DS field must not
be changed by IPsec decapsulation processing at the 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 the IETF, and may result in the need for brief
modifications of the appropriate security RFCs.
A tunnel egress node in a DS domain may modify the DS field in an
inner IP header based on the DS field value in the outer header,
including copying part or all of the outer DS field to the inner DS
field. 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 modifications are those
imposed by the domain's service provisioning policy. Otherwise, the
tunnel egress node performing such modifications is acting as a DS
ingress node for traffic exiting the tunnel, and must carry out the
responsibilities of an ingress node, including ensuring that the
resulting DS field values are acceptable (see Section 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 the outer DS
field value. 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 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, the source and destination IP
addresses, and the DS field value that was unacceptable. The
requirements in this paragraph apply to any future use of the
currently unused (CU) bits in the IPv4 TOS byte and the IPv6 Traffic
Class byte [DSFIELD].
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 also support auditing and
must allow a system administrator to enable or disable auditing for
differentiated services. 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 may 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.
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 1998.
[ATM] ATM Traffic Management Specification Version 4.0
<af-tm-0056.000>, April 1996.
[Baker] F. Baker, S. Brim, T. Li, F. Kastenholz, S. Jagannath,
and J. Renwick, "IP Precedence in Differentiated
Services Using the Assured Service", Internet Draft
<draft-ietf-diffserv-precedence-00.txt>, April 1998.
[DSFIELD] K. Nichols and S. Blake, "Definition of the
Differentiated Services Field (DS Byte) in the IPv4 and
IPv6 Headers", Internet Draft
<draft-ietf-diffserv-header-00.txt>, May 1998.
[DSFWK] Differentiated Services Framework Document (work in
preparation).
[Clark97] D. Clark and J. Wroclawski, "An Approach to Service
Allocation in the Internet", Internet Draft
<draft-clark-diff-svc-alloc-00.txt>, July 1997.
[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 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.
[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] T. Li and Y. Rekhter, "Provider Architecture for
Differentiated Services and Traffic Engineering (PASTE)",
Internet Draft <draft-li-paste-00.txt>, January 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] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", Internet RFC 2119, March 1997.
[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>,
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.
Authors' Addresses
David Black
The Open Group Research Institute
Eleven 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, Inc.
2990 Center Green Court South
Boulder, CO 80301
Phone: +1-303-448-0048 x115
E-mail: mac@redcape.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
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, et. al. Expires: November 1998 [Page 27]
