Internet Engineering Task Force Kathleen Nichols, editor
INTERNET-DRAFT Bay Networks Architecture Lab
Expires: August 1998 Steven Blake, editor
IBM Microelectronics
February 1998
Differentiated Services Operational Model and Definitions
<draft-nichols-dsopdef-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 learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
Differentiated services are intended to provide scalable service
discrimination in the Internet without the need for per-flow state
and signaling at every hop. The differentiated services approach to
providing quality of service in networks employs a small, well-
defined set of building blocks from which a variety of services may
be built. The services may be either end-to-end or intra-domain. A
wide range of services can be provided by a combination of:
- setting bits in the TOS octet at network edges and administrative
boundaries,
- using those bits to determine how packets are treated by the
routers inside the network, and
- conditioning the marked packets at network boundaries in accordance
with the requirements of each service.
A differentiated-services-capable network node includes a classifier
that selects packets based on the TOS octet and is capable of
delivering the treatment corresponding to that marking of the TOS
octet. Setting of the TOS octet and other conditioning of the
Nichols, et. al. Expires: August 1998 [Page 1]
INTERNET-DRAFT Differentiated Services February 1998
dynamic behavior of marked packets need only be performed at network
boundaries and may vary in complexity. This draft presents a
differentiated services definition of the TOS octet and the
operational model behind that definition.
Authors
This document is the result of a collaborative effort among the
following individuals: Fred Baker, Steve Blake, Scott Bradner, Scott
Brim, Brian Carpenter, Dave Clark, Eric Crawley, Bruce Davie, Juha
Heinanen, Geoff Huston, Van Jacobson, Jim Luciani, Kathleen Nichols,
Mike O'Dell, John Wroclawski, and Lixia Zhang.
0. Discussion of this draft
We have set up a public mailing list for discussions of this draft
and for other differentiated services BOF issues. The list is:
diff-serv@baynetworks.com. To subscribe send mail to
majordomo@baynetworks.com with the line "subscribe diff-serv" in the
body. A browsable archive for this mailing list is at
http://www-nrg.ee.lbl.gov/diff-serv-arch and the archive can be
downloaded from ftp://ftp.ee.lbl.gov/diff-serv-arch/. Please use
this mailing list rather than others for the discussion of
differentiated services.
1. Introduction
The TOS octet is used to mark a packet to receive a particular per-
hop behavior. Marking is performed by traffic conditioners at
network boundaries, including the edges of the network (first hop
router/switch) and administrative boundaries. Traffic conditioners
may include the primitives of classification, marking, policing and
shaping. Service classes can be specified by the use of particular
traffic conditioning at boundaries coupled with particular per-hop
behaviors. A goal of the differentiated services architecture is to
specify these building blocks for future extensibility, both of the
number and type of the building blocks and of the services built from
them.
A number of recent Internet Drafts have suggested various encodings
of the TOS byte to get specific behavior from network nodes on a per-
hop basis [Ellesson, Ferguson, Heinanen, SIMA] and others have
discussed the behaviors required from the network [Clark, 2BIT]. All
of these have made important points about the kinds of per-hop
behaviors that are considered in this note. In selecting the TOS
octet definition and specifying per-hop behaviors to attach to
particular bit-patterns, we have been influenced by all these drafts
and the thoughtful work of their authors.
Nichols, et. al. Expires: August 1998 [Page 2]
INTERNET-DRAFT Differentiated Services February 1998
We define terminology used in this draft in Sec. 2 and propose a
differentiated services definition for the TOS octet in Sec. 3. In
Sec. 4, we present an operational model for the assignment of per-hop
behaviors and propose two specific per-hop behaviors for
standardization. Sec. 5 describes primitives that can be used for
traffic conditioning. Sec. 6 discusses service allocation and
deployment and Sec. 7 covers some security considerations. We
present additional discussion of the TOS octet definition in Appendix
A and in Appendix B present some example services that can be built
from these differentiated services primitives.
2. Terminology used in this document
Service: The description of what is sold to a customer, specified
either end-to-end or within an Autonomous System (e.g., an ISP or
campus). We use the phrase "sold to a customer" loosely enough to
encompass any AS's allocation of network service to a user or
application.
Per-hop Behavior: The forwarding behavior a packet receives at a
given network node. It may be expressed in terms that can strongly
suggest a particular algorithm or implementation but leaves the
specific choice to the implementor. To compose predictable services,
per-hop behaviors probably need to be available in all routers in a
differentiated-services-capable network.
Mechanism: The implementation of a behavior.
Boundary: Where two network "clouds" are linked; the "clouds" can
represent different administrative domains or autonomous systems,
different trust regions, different network technologies (e.g., cell/
frame), hosts and routers, etc. A boundary can be further sub-
divided into exit and entry nodes, where the exit/entry nodes are the
upstream/downstream nodes of a boundary link in a given traffic
direction.
DS byte: the IP header TOS octet when configured in conformance with
the definition given in this document.
Differentiated services behavior aggregate: a collection of packets
with the same DS byte pattern crossing a boundary in a particular
direction. The terms "aggregate" and "behavior aggregate" will be
used interchangeably in this document.
Network edge: refers to a particular boundary node, the edge of the
differentiated-services-compliant area. This typically is at the
ingress to the first-hop differentiated-services-aware router (or
network node) a host's packets see or at the egress of the last-hop
differentiated-services-aware router or network node packets see
before arriving at a host. This is sometimes referred to as the
boundary at a leaf router. The network edge might be co-located with
Nichols, et. al. Expires: August 1998 [Page 3]
INTERNET-DRAFT Differentiated Services February 1998
a host, subject to local policy.
Traffic conditioning primitives: functions that can be applied to a
behavior aggregate, flow, or other operationally useful subset of
traffic, e.g., routing updates. These include policing, shaping,
header classification, and packet marking. Again, these may be
described in terms that can strongly suggest a particular algorithm
or implementation but no specific choice of implementation is given.
With the exception of a DS byte classifier at the packet forwarding
engine, traffic conditioning primitives need not be implemented in
all network nodes in a differentiated-services-capable network,
instead appearing primarily at boundaries.
To summarize, the TOS octet is used as a DS byte to designate
behaviors. A DS byte classifier and per-hop behaviors based on those
classifications are required in all network nodes of a
differentiated-services-capable network. More extensive traffic
conditioners may appear at boundaries. Multiple services can be
supported by a single per-hop behavior used in concert with a range
of traffic conditioners.
3. A Differentiated Services Definition of the TOS Octet
We propose to redefine the structure for the 8-bit IPv4 TOS field
[RFC791] and the 8-bit IPv6 Class field [IPv6], and re-label the
field as the "DS byte". The new structure is presented below:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|IN | PHB | CU |
+---+---+---+---+---+---+---+---+
IN: in (1) or out (0) of profile
PHB: per-hop behavior
CU: currently unused (reserved)
We have been influenced by [Ellesson] and by Dave Clark's talk at the
int-serv WG December 8, 1997 meeting. Adopting key elements of
Clark's framework, though not the exact terminology or bit-patterns,
we use five bits to define the per-hop behavior (PHB) the packet
experiences and one bit (IN) to identify whether the packet may be
in- or out-of-profile with respect to some traffic policy measured at
a network boundary. We also reserve a two-bit CU, or currently
unused, field that may be assigned later, e.g., for explicit
congestion notification [ECN]. Hosts SHOULD set the CU bits to
zeroes, and traffic conditioners and routers SHOULD ignore their
value.
The IN indicator parameter may be used to mark packets for a higher
Nichols, et. al. Expires: August 1998 [Page 4]
INTERNET-DRAFT Differentiated Services February 1998
level of service (e.g., lower loss probability) within whatever share
of router interface resources (e.g., buffers, bandwidth) are
associated with a particular per-hop behavior.
Router implementations SHOULD treat the 5-bit PHB field as an index
to be used in selecting a particular packet handling mechanism which
has been implemented in that device. Although the IANA may assume
some structure within the PHB field when assigning values for new
per-hop behaviors, implementations should treat it as an unstructured
field.
The structure of the DS byte shown above is incompatible with the
existing definition of the IPv4 TOS octet in [RFC791, RFC1349]. The
use of bit 7 as a "DiffServ semantics" indicator was contemplated,
but the authors believe that there exists deployed equipment which
does not test bit 7, thereby making it impossible to simultaneously
support two sets of semantics within the same network. Therefore, to
maintain compatibility with IPv4 hosts and networks which utilize the
existing TOS semantics, a differentiated services-enabled network
MUST remark the TOS value of packets arriving at a boundary entry
node to some acceptable value within the new semantics, and MAY
remark (e.g., by zeroing) on exit at a boundary to a network
supporting the existing semantics. Validating the value of the TOS
octet at network boundaries is sensible in any case since an upstream
node can easily set them to any random value. Differentiated-
services-enabled networks which are not suitably isolated by a
remarking boundary node may deliver unpredictable service.
4. Operational Model
4.1 Per-Hop Behaviors
The differentiated services model is that a router has a (possibly
large) set of parameters that can be used to control how packets are
scheduled onto an output interface (e.g., N separate queues with
settable priorities, queue lengths, round-robin weights, drop
algorithm, drop preference weights and thresholds, etc). Router
vendors are free to offer whatever parameters and capabilities they
feel are useful or marketable. An ISP is free to configure those
parameters in whatever way they feel is appropriate for their service
offerings and traffic engineering objectives. The router's
capabilities and its particular configuration determine the different
ways packets can be treated. The DS byte then selects which
treatment a particular packet receives. For example, an ISP may
configure eight weighted round robin queues in its routers and use
the DS byte to select which queue (from zero, for smallest weight to
seven, for largest weight or share of output link) a packet is placed
for servicing. Another ISP might configure a single queue with
multiple drop priorities and use the DS byte to select the drop
preference (from zero, most likely to drop to seven, least likely to
drop) for packets in that queue. Another might configure four queues
Nichols, et. al. Expires: August 1998 [Page 5]
INTERNET-DRAFT Differentiated Services February 1998
with two levels of drop preference in each. There is no requirement
that different ISPs use the same router mechanisms or configuration
or that any value of the DS byte map to a particular packet
forwarding behavior (other than the behaviors described below and the
general guidelines given in Appendix A).
However, to the extent that the per-hop behaviors are used to
implement end-to-end services (see Appendix B for examples), it may
be undesirable for the "same" per-hop behavior to be selected by
different DS byte values in different ISPs. For example, consider
ISP A and ISP B both offering a low jitter, guaranteed rate, premium
service. If ISP A uses a PHB of 3 to select an appropriate router
mechanism while ISP B uses a PHB of 7, packets that use this service
and transit A to B must have the PHB field of their DS byte rewritten
from 3 to 7. Since the per-hop behaviors on each side must be
functionally equivalent, this is simply useless work that has to be
done in the forwarding path of a busy border router. To avoid this,
we expect that over time certain common per-hop behaviors will evolve
(ones that are particularly useful for implementing end-to-end
services) and that these will be associated with particular code
points in the DS byte. However, since our current experience with
diffserv is quite limited, it is premature to hypothesize the exact
specification of these code points and we have simply left room in
the code space to allow for evolution, thus the defined space of the
PHB field is intentionally sparse. But we do not suggest that PHB
patterns be selected and assigned without adherence to a larger
context. For more on the rationale of selecting and using PHBs, see
Appendix A.
Only those per-hop behaviors that have both some degree of
orthogonality and have been implemented, deployed, and shown to be
useful should be standardized.
Two per-hop behaviors are already in widespread use and we propose
them for standardization: Default (DE) is the common, best-effort
forwarding available in today's internet and already standardized in
RFC-1812. Expedited Forwarding (EF) is a "high priority" behavior
typically used for network control traffic such as routing updates.
The code points chosen for these are compatible with existing
practice:
PHB field value Behavior name
--------------- -------------
00000 Default (DE)
11100 Expedited Forwarding (EF)
and are defined as follows:
Nichols, et. al. Expires: August 1998 [Page 6]
INTERNET-DRAFT Differentiated Services February 1998
Default: an incoming packet goes to the tail of a queue that is
serviced in FIFO order when the output link is free. Thus if a
continuous stream of DE-marked packets is sent into a device, packets
that emerge will emerge in the same order they entered. It is not
required that all arriving packets are seen at the output, but it is
required that the aggregate of packets with this marking are not
completely starved. Delay requirements are as soon as possible, and
the corresponding bandwidth requirements are as much as possible
(subject to the other constraints of the router's scheduling system)
[CCBES]. The Default behavior is designed to closely approximate the
best-effort behavior of existing routers.
Expedited Forwarding: an EF-marked packet goes to the tail of a queue
that is expected to be relatively short and which always gets the
next opportunity to send a packet (possibly subject to some rate
regulator policy which prevents starvation of the Default queue).
Thus, when an EF-marked packet is sent into a device, that packet
should emerge at the output within a very small number of packet
times. The expedited forwarding behavior may be used to implement
services requiring low delay and low jitter, and may also be useful
for network control traffic.
Even though the above behaviors have been encoded in 3 bits,
implementors should note that the PHB field is 5 bits wide and
routers MUST identify both the DE and EF PHBs by matching against the
entire 5-bit PHB field. Packets received with an unrecognized PHB
value SHOULD be handled as if they were marked for DE.
Note that precise definitions of PHBs can be unwieldy and unclear.
For this reason, the PHBs above are described as the output of an
example algorithm. However, PHBs should be standardized, not the
algorithms or the mechanisms used to implement them. To illustrate
the distinction between PHB and mechanism, we point out that the EF
PHB can be implemented by several mechanisms, including: a strict
priority queue, WFQ or variants [HPFQA], weighted round-robin with a
large weight for the EF queue, or CBQ [CBQ].
4.2 The "In Profile" bit
Packets marked with the IN bit set should experience a probability of
loss or congestion indication which is always less than or equal to
that experienced by packets with the IN bit cleared. When the IN bit
is used, RIO [Clark] or another drop preference or congestion
indication mechanism may be used to implement its use. The
requirements on a drop preference mechanism may be specific to each
per-hop behavior, but the general requirements include: (1) there
should be no packet reordering between packets marked for this
behavior; (2) The *average* (real or virtual) queue occupancy should
be used in the drop or congestion notification calculation, in a way
that maximizes the router's chances of selecting a non-preferred
packet to drop or notify of congestion.
Nichols, et. al. Expires: August 1998 [Page 7]
INTERNET-DRAFT Differentiated Services February 1998
In the absence of traffic profiles, we suggest the IN bit should be
set to zero for Default traffic. With traffic profiles, the IN bit
can be used to provide further service differentiation of DE-marked
packets; for example, it can be used to implement the Assured service
described in [Clark].
Use of the IN bit in combination with the EF PHB is a subject of
further research; at this time, all packets marked EF should have the
IN bit set. A pattern of 0.EF.CU will be considered undefined. The
use of the IN bit as an in-profile indicator with the EF PHB is
problematic for two reasons. First, the delay and jitter behavior of
EF-marked packets is sensitive to the relative load of EF-marked
packets on a link; service allocation policies and traffic
conditioners are used to ensure that this load is small enough to
permit the desired low-delay behavior to be realized. Secondly, out-
of-profile EF-marked packets receive priority relative to DE-marked
packets; excessive out-of-profile EF-marked packets may degrade the
service of the DE-marked aggregate beyond what is assumed in the
domain's service allocation policy.
5. Example Traffic Conditioners for Boundaries
Recall from Sec. 2 that traffic conditioners are composed of one or
more primitives: classifiers, markers, policers, and shapers.
Traffic conditioners prepare behavior aggregates for differentiated
services. The primitives are defined as:
Classifiers: select packets based on some portion of their packet
header and steer packets matching some classifier rule to another
traffic conditioner for further processing. Classifiers are of two
types: multi-field (MF) classifiers which can classify on the DS byte
as well as any one of a number of header fields (like a RSVP
classifier) and behavior aggregate (BA) classifiers which classify
only on patterns in the DS byte.
Markers: set the DS byte to a particular bit pattern, adding the
marked packets to a particular differentiated services behavior
aggregate.
Policers: monitor the the dynamic behavior of the packets steered to
them by a classifier and take an action (usually remarking or
dropping packets) based on the relationship of measured properties of
the packet stream to configured properties (e.g., rate and burst).
Policers are generally placed after either type of classifier: after
MF classifiers (e.g., at a host/network or site/provider boundary)
or after BA classifiers (e.g., at a provider/provider boundary).
Shapers: cause conformance to some configured traffic properties
(e.g., token bucket). Like policers, shapers are generally placed
after either type of classifier. Only one of the two primitives,
policers or shapers, would be expected to appear in the same traffic
Nichols, et. al. Expires: August 1998 [Page 8]
INTERNET-DRAFT Differentiated Services February 1998
conditioner.
Although it is probably not necessary to standardize traffic
conditioners or the primitives that compose them, traffic
conditioners are required to instantiate services, and to enforce
service allocation policies. The only conditioning that is required
for packets of a differentiated services aggregate is to set the DS
byte appropriately. Thus, the simplest traffic conditioner consists
of only a packet marker that sets the DS byte of every packet on its
interface to a particular pattern for a particular per-hop behavior.
If the service being offered requires additional rule conformance,
then other primitives must be added to the traffic conditioner.
Another simple traffic conditioner might use an MF classifier to
select packets with a particular source-destination pair and a marker
to set these packets' DS byte to for a particular per-hop behavior.
There are a number of ways to condition traffic at boundaries; see
[Clark], [SIMA], and [2BIT]. We expect that many more might evolve
as differentiated services is widely deployed.
Applications SHOULD be aware that the value of the DS byte may be
modified at each network boundary (possibly subject to some
negotiated policy). The value of the DS byte does not have end-to-
end integrity; security and transport protocol checksums MUST not
include this field.
6. Service Allocation and Deployment
As differentiated services are deployed, there will be concerns about
service allocation and also about partial deployment. The allocation
of differentiated services does not require standardization or
uniformity. The differentiated services architecture leads quite
naturally to a control structure where decisions about the rate of
each type of marked packet are made on a per-domain basis. Since
traffic carried on a link between two domains can now be classified
into a small set of possibilities, it should be relatively
straightforward to write down a bilateral agreement between any two
domains. Differentiated services does not require end-to-end
signaling, but permits each domain to develop allocations of its
intra-domain traffic according to rules and processes that are as
simple or complex as desired. Inter-domain agreements can be as
simple as a list of the different packet markings and a maximum rate
permitted for each. Thus, it is not necessary to standardize a
service allocation strategy to deploy differentiated services.
We expect that a number of allocation methods will be tried within
different domains: aggregated RSVP [AIISS, GBH], Bandwidth Brokers
[2BIT], human configuration by a network manager. Reports of
experiences with different intra-domain allocation methods should
prove valuable during early deployment. Further, we expect the
nature of the bilateral inter-domain agreements to evolve as
experience is with differentiated services is gained. Again, reports
Nichols, et. al. Expires: August 1998 [Page 9]
INTERNET-DRAFT Differentiated Services February 1998
on experience will do much to advance the field.
Differentiated services are realized by the concatenation of per-hop
behaviors along the transit path of a packet; therefore, the
treatment experienced by a behavior aggregate along a particular path
is unpredictable if some of the nodes along that path do not
recognize and implement the proposed per-hop behaviors. Note however
that the behavior of a router on a lightly loaded, high-speed link
which does not implement a set of per-hop behaviors may be
indistinguishable from that of a router which does (since the
proposed per-hop behaviors are work-conserving). The choice of those
nodes upon which to implement the proposed per-hop behaviors is
subject to a domain's traffic engineering policy.
Experiences with early deployment of differentiated services should
be shared, creating a body of work that the community can draw upon
when deploying differentiated services in a domain or when automating
a formerly manual process of allocation. Ultimately, we expect that
at least some differentiated services will enlist the use of
automated inter-domain messaging to provide more flexibility.
Selecting and developing the best approach is a topic for research.
Though, ultimately, we may need a standard format for these messages,
this should not be an IETF topic in the near-term.
7. Security Considerations
Wide-spread deployment of IP Security obscures the IP- and transport-
header fields which are frequently used to enable packet
classification for service differentiation. Use of the DS byte
offers an alternative means of classification for differentiated
services, thereby eliminating a disincentive to the deployment of IP
Security (especially within virtual private networks using ESP in
tunnel-mode [ESP]).
Because the differentiated services per-hop behaviors introduce
service bias, new denial-of-service attacks may be introduced. As an
example, unauthorized use of the EF PHB or IN bit may result in
service degradation to other traffic flows. Furthermore, an attack
on the differentiated services authorization, signaling, or
configuration mechanisms may permit theft-of-service or may enable a
severe denial-of-service attack. As a consequence, authorization,
signaling, and configuration mechanisms must be strongly protected
(e.g., by authentication). Non-default per-hop behaviors should
always be controlled at a network boundary via some traffic
conditioner (classifier, marker, policer/shaper).
The IP Security Authentication Header (AH) does not cover the IPv4
TOS octet in the integrity check value computation [AH]. This
behavior is in fact essential for the deployment of differentiated
services since the value of the DS byte may be changed in transit so
that the source host does not know what value will be delivered to
Nichols, et. al. Expires: August 1998 [Page 10]
INTERNET-DRAFT Differentiated Services February 1998
the destination host. Also, since the network is free to ignore the
DS byte, end-to-end integrity of a DS byte value does not guarantee
that a differentiated service has been delivered. Separate
measurement and assurance mechanisms are needed to ensure that any
negotiated differentiated services are being provided.
8. Acknowledgements
In addition to the co-authors of this document, valuable input was
received from Jim Boyle and Sally Floyd.
9. References
[AH] S. Kent and R. Atkinson, "IP Authentication Header",
Internet Draft <draft-ietf-ipsec-auth-header-02.txt>,
October 1997.
[AIISS] S. Berson and S. Vincent, "Aggregation of Internet
Integrated Services State", Internet Draft
<draft-berson-classy-approach-01.txt>, November 1997.
[CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource
Management Models for Packet Networks", IEEE/ACM
Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
August 1995.
[CCBES] C. Lefelhocz, B. Lyles, S. Shenker, and L. Zhang,
"Congestion Control for Best-Effort Service: Why We Need
a New Paradigm", IEEE Network, Vol. 10, no. 1, January
1996.
[Clark] D. Clark and J. Wroclawski, "An Approach to Service
Allocation in the Internet", Internet Draft
<draft-clark-diff-svc-alloc-00.txt>, July 1997.
[ECN] K. Ramakrishnan and S. Floyd, "A Proposal to Add Explicit
Congestion Notification (ECN) to IPv6 and to TCP",
Internet Draft <draft-kksjf-ecn-00.txt>, November 1997.
[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.
[ESP] S. Kent and R. Atkinson, "IP Encapsulating Security
Payload", Internet Draft
<draft-ietf-ipsec-esp-v2-01.txt>, October 1997.
Nichols, et. al. Expires: August 1998 [Page 11]
INTERNET-DRAFT Differentiated Services February 1998
[Ferguson] P. Ferguson, "Simple Differential Services: IP TOS and
Precedence, Delay Indication, and Drop Preference,
Internet Draft <draft-ferguson-delay-drop-00.txt>,
November 1997.
[GBH] R. Guerin, S. Blake, and S. Herzog, "Aggregating RSVP-
based QoS Requests", Internet Draft
<draft-guerin-aggreg-rsvp-00.txt>, November 1997.
[Heinanen] J. Heinanen, "Use of the IPv4 TOS Octet to Support
Differentiated Services", Internet Draft
<draft-heinanen-diff-tos-octet-01.txt>, November 1997.
[HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair
Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996.
[IPv6] S. Deering and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", Internet Draft
<draft-ietf-ipngwg-ipv6-spec-v2-01.txt>, November 1997.
[RFC791] Information Sciences Institute, "Internet Protocol",
Internet RFC 791, September 1981.
[RFC1349] P. Almquist, "Type of Service in the Internet Protocol
Suite", Internet RFC 1349, July 1992.
[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.
Appendix A. Proposed Interpretation of the Three Most-Significant Bits
of the PHB Field
In this document, we have proposed two particular PHBs. Observant
readers will note that the numerical value of the PHB field assigned
to the Expedited Forwarding behavior is greater than that assigned to
the Default behavior. This is compatible with the interpretation of
the three most-significant bits of the PHB field (bits 1, 2, and 3 of
the DS byte as shown in Sec. 3) as a "weight" or "traffic precedence"
relative to some dimension of quality of service (e.g., delay,
throughput, or loss). We propose that implementors use bits 1, 2,
and 3 as a weight parameter to enable experiments using multi-level
priority (of loss, delay, and/or throughput), subject to the
requirement that bits 4 and 5 of the DS byte have the value zero.
The associated weight (e.g., increased delay priority, increased link
share, decreased loss probability) should increase in the order of
Nichols, et. al. Expires: August 1998 [Page 12]
INTERNET-DRAFT Differentiated Services February 1998
increasing numerical value of bits 1, 2, and 3. The interpretation
of bits 1, 2, and 3 when the value of bits 4 and 5 is not equal to
zero is not defined.
Because this proposal does not specify the specific QoS metric which
is affected by this three bit weight, implementation of any
particular differentiated service using this parameter is dependent
on each router's interpretation and implementation of the weight.
Potential behaviors which could utilize this weight field include
multi-level delay priority, multi-level discard priority, or multiple
link shares (where the share of a link increases in the order of
increasing weight).
Appendix B. Service Examples in this Framework
We propose standardizing ONLY a new meaning for the TOS octet and
particular per-hop behaviors associated with certain TOS octet
patterns. These will provide predictable building blocks from which
a variety of services might be built. There is thus no need to
standardize the services as these are realized by combining traffic
conditioners at boundaries with per-hop behaviors. To illustrate
this, we present some example services implemented in our framework.
We do not attempt to define "quality of service" for applications nor
do we make assumptions about what service a particular application
might use. Thus, although we give some example uses, we do not
characterize the services as being "for real-time video" or "for file
transfer data". Instead, we characterize a service by the type of
performance packets of that service can expect from the network. Any
IP application can utilize any of the services; the choice is up to
the customer.
Service: Best Effort
Service definition: "like today" (as soon as possible; as much as
possible [CCBES]).
Who/how to use this: The basic service of the Internet, what one gets
when merely buying connectivity.
Service: Premium
Service definition: Premium service is a peak-limited, extremely low-
delay service, resembling a leased line [2BIT]. At the network edge,
where a Premium aggregate is first created, it must be either shaped
or policed to a rate with no more than a two-packet burst. A policer
for Premium service is set to drop packets which exceed the
configured peak rate. For this service, the peak rate of the Premium
aggregate across any boundary must be specified and the rate must be
smaller than the link capacity (in practice, it is expected to be a
good deal less than the link capacity). Policing to this rate is
expected at the ingress of any domain and the policing action taken
may be one of two possibilities only: 1) drop the over-rate packet
Nichols, et. al. Expires: August 1998 [Page 13]
INTERNET-DRAFT Differentiated Services February 1998
and 2) hold the over-rate packet until it will be in compliance with
the peak rate (shaping).
Who/how to use this: Voice-over-IP "trunk", videoconference, fixed
size transfer in fixed time, virtual leased line, low delay
applications.
Service name: Assured
Service definition: Assured service is characterized by a rate and
burst profile [Clark]. Behavior aggregates that conform to their
profile are unlikely to experience dropped packets. Packets sent
that are out-of-profile are serviced with a higher drop preference,
but are not reordered with respect to in-profile packets. At the
network edge, an assured behavior aggregate is marked for DE, the IN
bit is set, and it is policed to a configured rate and burst size. A
policer for assured service clears the IN bit of packets which exceed
the configured rate, thus tagging them as "out-of-profile". The IN
bit is only used if there is congestion on a link, then "out" packets
are dropped with higher probability than "in" packets. The sum of
the Assured rates along with all other reserved rates at a domain
ingress should be less than the total available rate. Packets must
remain marked for DE as reordering is prohibited.
Who/how to use this: fixed file transfer size in desired time,
"better effort", certain adaptive applications.
Though we believe it is too early to standardize more than the EF and
DE PHBs, we describe a service that can be delivered with a "link
share" interpretation of bits 1, 2, and 3 of the DS byte as described
in Appendix A.
Service name: Olympic
Service definition: Olympic service provides three levels of service,
gold, silver, and bronze, in decreasing order of congested link
shares. Deployment of this service requires the implementation of
a rate-based link share scheduler behavior at each hop [HPFQA, CBQ].
The particular link share associated with a packet could be selected
as suggested in Appendix A. When encountering a congested link,
packets with "Olympic gold" service will get a larger share of the
link than packets sent using the "Olympic silver" service which gets
a larger share of the link than packets sent using the "Olympic
bronze" service. When there are no packet flows of gold or silver
(or other higher serviced flows), bronze packet flows may utilize the
entire output link. This service classifies flows at a boundary,
marking packets for link share (e.g., by setting the "weight"
parameter in bits 1, 2, and 3) and setting the IN bit. The weight
parameter could be set to i for gold flow packets, i-1 for silver
flow packets, and i-2 for bronze flow packets, where 2 < i < 7.
Classification should be uniform across a single TCP flow or packet
reordering may result. The exact method of service discrimination
Nichols, et. al. Expires: August 1998 [Page 14]
INTERNET-DRAFT Differentiated Services February 1998
among the parameters is not specified, but would presumably be
selected so as to make a perceptible difference to customers. For
example, if the mechanism implementing link sharing has four weighted
round robin queues with RIO droppers in each queue, a configuration
might be 60% for gold, 30% for silver, 10% for bronze. These are the
percentages each aggregate gets when the link is congested, but an
alternate specification is that silver would get three times as large
a share of service as bronze and gold would get twice the service of
silver (it is also possible to have a "hidden" majority share
reserved for EF traffic). Lengths of each queue might also be
adjusted to meet certain requirements (this is a configuration option
which would not be standardized). Customers do not specify a
particular traffic profile, flows are not admission-controlled, and
flows are not shaped or policed in any way.
Who/how use this: for customer discrimination within an ISP,
corporate, or campus domain.
Editors' Addresses
Kathleen Nichols
Bay Networks Architecture Lab
4401 Great America Parkway
SC01-04
Santa Clara, CA 95052-8185
Phone: +1-408-495-3252
Fax: +1-408-495-1299
E-mail: knichols@baynetworks.com
Steven Blake
IBM Microelectronics
C5BA 660/HH007
800 Park Offices Drive
Research Triangle Park, NC 27709
Phone: +1-919-254-2030
Fax: +1-919-254-3047
E-mail: slblake@raleigh.ibm.com
Nichols, et. al. Expires: August 1998 [Page 15]
