draft-ietf-diffserv-model-05.txt   draft-ietf-diffserv-model-06.txt 
Internet Engineering Task Force Y. Bernet Internet Engineering Task Force Y. Bernet
Diffserv Working Group Microsoft Diffserv Working Group Microsoft
INTERNET-DRAFT S. Blake INTERNET-DRAFT S. Blake
Expires May 2001 Ericsson Expires August 2001 Ericsson
draft-ietf-diffserv-model-05.txt D. Grossman draft-ietf-diffserv-model-06.txt D. Grossman
Motorola Motorola
A. Smith A. Smith
Allegro Networks Allegro Networks
November 2000 February 2001
An Informal Management Model for Diffserv Routers An Informal Management Model for Diffserv Routers
***** Preliminary Authors' Review DRAFT *****
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 1, line 35 skipping to change at page 1, line 35
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft
Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This document is a product of the IETF's Differentiated Services working This document is a product of the IETF's Differentiated Services working
group. Comments should be addressed to WG's mailing list at group. Comments should be addressed to WG's mailing list at
diffserv@ietf.org. The charter for Differentiated Services may be found diffserv@ietf.org. The charter for Differentiated Services may be found
at http://www.ietf.org/html.charters/diffserv-charter.html Copyright (C) at http://www.ietf.org/html.charters/diffserv-charter.html
The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (2001). All Rights Reserved.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Abstract Abstract
This document proposes an informal management model of Differentiated This document proposes an informal management model of Differentiated
Services (Diffserv) routers for use in their management and Services (Diffserv) routers for use in their management and
configuration. This model defines functional datapath elements (e.g. configuration. This model defines functional datapath elements (e.g.
classifiers, meters, actions (e.g. marking, absolute dropping, counting, classifiers, meters, actions (e.g. marking, absolute dropping, counting,
multiplexing), algorithmic droppers, queues and schedulers. It describes multiplexing), algorithmic droppers, queues and schedulers. It describes
possible configuration parameters for these elements and how they might possible configuration parameters for these elements and how they might
skipping to change at page 2, line 31 skipping to change at page 2, line 30
kinds of network quality-of-service (QoS) objectives to different kinds of network quality-of-service (QoS) objectives to different
customers and their traffic streams. This document uses terminology customers and their traffic streams. This document uses terminology
defined in [DSARCH] and other work-in-progress from the IETF's Diffserv defined in [DSARCH] and other work-in-progress from the IETF's Diffserv
working group (some of these definitions are included here in Section 2 working group (some of these definitions are included here in Section 2
for completeness). for completeness).
The premise of Diffserv networks is that routers within the core of the The premise of Diffserv networks is that routers within the core of the
network handle packets in different traffic streams by forwarding them network handle packets in different traffic streams by forwarding them
using different per-hop behaviors (PHBs). The PHB to be applied is using different per-hop behaviors (PHBs). The PHB to be applied is
indicated by a Diffserv codepoint (DSCP) in the IP header of each packet indicated by a Diffserv codepoint (DSCP) in the IP header of each packet
[DSFIELD]. The DSCP markings are applied either by a trusted customer or [DSFIELD]. The DSCP markings are applied either by a trusted upstream
by the edge routers on entry to the Diffserv network. node, e.g. a customer, or by the edge routers on entry to the Diffserv
network.
The advantage of such a scheme is that many traffic streams can be The advantage of such a scheme is that many traffic streams can be
aggregated to one of a small number of behavior aggregates (BA) which aggregated to one of a small number of behavior aggregates (BA) which
are each forwarded using the same PHB at the router, thereby simplifying are each forwarded using the same PHB at the router, thereby simplifying
the processing and associated storage. In addition, there is no the processing and associated storage. In addition, there is no
signaling, other than what is carried in the DSCP of each packet, and no signaling, other than what is carried in the DSCP of each packet, and no
other related processing that is required in the core of the Diffserv other related processing that is required in the core of the Diffserv
network since QoS is invoked on a packet-by-packet basis. network since QoS is invoked on a packet-by-packet basis.
The Diffserv architecture enables a variety of possible services which The Diffserv architecture enables a variety of possible services which
could be deployed in a network. These services are reflected to could be deployed in a network. These services are reflected to
customers at the edges of the Diffserv network in the form of a Service customers at the edges of the Diffserv network in the form of a Service
Level Specification (SLS - see section 2). The ability to provide these Level Specification (SLS - see section 2). Whilst further discussion of
services depends on the availability of cohesive management and such services is outside the scope of this document (see [PDBDEF]), the
configuration tools that can be used to provision and monitor a set of ability to provide these services depends on the availability of
Diffserv routers in a coordinated manner. To facilitate the development cohesive management and configuration tools that can be used to
of such configuration and management tools it is helpful to define a provision and monitor a set of Diffserv routers in a coordinated manner.
conceptual model of a Diffserv router that abstracts away implementation To facilitate the development of such configuration and management tools
details of particular Diffserv routers from the parameters of interest it is helpful to define a conceptual model of a Diffserv router that
for configuration and management. The purpose of this document is to abstracts away implementation details of particular Diffserv routers
define such a model. from the parameters of interest for configuration and management. The
purpose of this document is to define such a model.
The basic forwarding functionality of a Diffserv router is defined in The basic forwarding functionality of a Diffserv router is defined in
other specifications; e.g., [DSARCH, DSFIELD, AF-PHB, EF-PHB]. other specifications; e.g., [DSARCH, DSFIELD, AF-PHB, EF-PHB].
This document is not intended in any way to constrain or to dictate the This document is not intended in any way to constrain or to dictate the
implementation alternatives of Diffserv routers. It is expected that implementation alternatives of Diffserv routers. It is expected that
router implementers will demonstrate a great deal of variability in router implementers will demonstrate a great deal of variability in
their implementations. To the extent that implementers are able to model their implementations. To the extent that implementers are able to model
their implementations using the abstractions described in this document, their implementations using the abstractions described in this document,
configuration and management tools will more readily be able to configuration and management tools will more readily be able to
skipping to change at page 5, line 31 skipping to change at page 5, line 31
discarding them. discarding them.
Scheduling An algorithm which determines which queue of a set Scheduling An algorithm which determines which queue of a set
algorithm of queues to service next. This may be based on the algorithm of queues to service next. This may be based on the
relative priority of the queues, on a weighted fair relative priority of the queues, on a weighted fair
bandwidth sharing policy or some other policy. Such bandwidth sharing policy or some other policy. Such
an algorithm may be either work-conserving or non- an algorithm may be either work-conserving or non-
work-conserving. work-conserving.
Service-Level A set of parameters and their values which together Service-Level A set of parameters and their values which together
Specification define the service offered to a traffic stream by a Specification define the treatment offered to a traffic stream by a
(SLS) Diffserv domain. (SLS) Diffserv domain.
Shaping The process of delaying packets within a traffic stream Shaping The process of delaying packets within a traffic stream
to cause it to conform to some defined temporal profile. to cause it to conform to some defined temporal profile.
Shaping can be implemented using a queue serviced by a Shaping can be implemented using a queue serviced by a
non-work-conserving scheduling algorithm. non-work-conserving scheduling algorithm.
Traffic A logical datapath entity consisting of a number of Traffic A logical datapath entity consisting of a number of
Conditioning functional datapath elements interconnected in Conditioning functional datapath elements interconnected in
Block (TCB) such a way as to perform a specific set of traffic Block (TCB) such a way as to perform a specific set of traffic
skipping to change at page 8, line 40 skipping to change at page 8, line 40
Diffserv routers may snoop or participate in either per-microflow or Diffserv routers may snoop or participate in either per-microflow or
per-flow-aggregate signaling of QoS requirements [E2E] e.g. using the per-flow-aggregate signaling of QoS requirements [E2E] e.g. using the
RSVP protocol. Snooping of RSVP messages may be used, for example, to RSVP protocol. Snooping of RSVP messages may be used, for example, to
learn how to classify traffic without actually participating as a RSVP learn how to classify traffic without actually participating as a RSVP
protocol peer. Diffserv routers may reject or admit RSVP reservation protocol peer. Diffserv routers may reject or admit RSVP reservation
requests to provide a means of admission control to Diffserv-based requests to provide a means of admission control to Diffserv-based
services or they may use these requests to trigger provisioning changes services or they may use these requests to trigger provisioning changes
for a flow-aggregation in the Diffserv network. A flow-aggregation in for a flow-aggregation in the Diffserv network. A flow-aggregation in
this context might be equivalent to a Diffserv BA or it may be more this context might be equivalent to a Diffserv BA or it may be more
fine-grained, relying on a MF classifier [DSARCH]. Note that the fine-grained, relying on a multi-field (MF) classifier [DSARCH]. Note
conceptual model of such a router implements the Integrated Services that the conceptual model of such a router implements the Integrated
Model as described in [INTSERV], applying the control plane controls to Services Model as described in [INTSERV], applying the control plane
the data classified and conditioned in the data plane, as desribed in controls to the data classified and conditioned in the data plane, as
[E2E]. desribed in [E2E].
Note that a QoS Agent component of a Diffserv router, if present, might Note that a QoS Agent component of a Diffserv router, if present, might
be active only in the control plane and not in the data plane. In this be active only in the control plane and not in the data plane. In this
scenario, RSVP could be used merely to signal reservation state without scenario, RSVP could be used merely to signal reservation state without
installing any actual reservations in the data plane of the Diffserv installing any actual reservations in the data plane of the Diffserv
router: the data plane could still act purely on Diffserv DSCPs and router: the data plane could still act purely on Diffserv DSCPs and
provide PHBs for handling data traffic without the normal per-microflow provide PHBs for handling data traffic without the normal per-microflow
handling expected to support some Intserv services. handling expected to support some Intserv services.
3.2. Diffserv Functions at Ingress and Egress 3.2. Diffserv Functions at Ingress and Egress
This document focuses on the Diffserv-specific components of the router. This document focuses on the Diffserv-specific components of the router.
Figure 2 shows a high-level view of ingress and egress interfaces of a Figure 2 shows a high-level view of ingress and egress interfaces of a
router. The diagram illustrates two Diffserv router interfaces, each router. The diagram illustrates two Diffserv router interfaces, each
having a set of ingress and a set of egress elements. It shows having a set of ingress and a set of egress elements. It shows
classification, metering, action and queueing functions which might be classification, metering, action and queueing functions which might be
instantiated at each interface's ingress and egress. instantiated at each interface's ingress and egress.
The simple diagram of Figure 2 assumes that the set of Diffserv
functions to be carried out on traffic on a given interface are
independent of those functions on all other interfaces. There are some
architectures where Diffserv functions may be shared amongst multiple
interfaces e.g. processor and buffering resources that handle multiple
interfaces on the same line card before forwarding across a routing
core. The model presented in this document may be easily extended to
handle such cases; however, this topic is not treated further here as it
leads to excessive complexity in the explanation of the concepts.
In principle, if one were to construct a network entirely out of two- In principle, if one were to construct a network entirely out of two-
port routers (connected by LANs or similar media), then it might be port routers (connected by LANs or similar media), then it might be
necessary for each router to perform four QoS control functions in the necessary for each router to perform four QoS control functions in the
datapath on traffic in each direction: datapath on traffic in each direction:
- Classify each message according to some set of rules, possibly just
a "match everything" rule.
- If necessary, determine whether the data stream the message is part
of is within or outside its rate by metering the stream.
- Perform a set of resulting actions, including applying a drop
policy appropriate to the classification and queue in question and
perhaps additionally marking the traffic with a Differentiated
Services Code Point (DSCP) [DSFIELD].
Interface A Interface B Interface A Interface B
+-------------+ +---------+ +-------------+ +-------------+ +---------+ +-------------+
| ingress: | | | | egress: | | ingress: | | | | egress: |
| classify, | | | | classify, | | classify, | | | | classify, |
--->| meter, |---->| |---->| meter, |---> --->| meter, |---->| |---->| meter, |--->
| action, | | | | action, | | action, | | | | action, |
| queueing | | routing | | queueing | | queueing | | routing | | queueing |
+-------------+ | core | +-------------+ +-------------+ | core | +-------------+
| egress: | | | | ingress: | | egress: | | | | ingress: |
| classify, | | | | classify, | | classify, | | | | classify, |
<---| meter, |<----| |<----| meter, |<--- <---| meter, |<----| |<----| meter, |<---
| action, | | | | action, | | action, | | | | action, |
| queueing | +---------+ | queueing | | queueing | +---------+ | queueing |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 2. Traffic Conditioning and Queueing Elements Figure 2. Traffic Conditioning and Queueing Elements
- Classify each message according to some set of rules, possibly just
a "match everything" rule.
- If necessary, determine whether the data stream the message is part
of is within or outside its rate by metering the stream.
- Perform a set of resulting actions, including applying a drop
policy appropriate to the classification and queue in question and
perhaps additionally marking the traffic with a Differentiated
Services Code Point (DSCP) [DSFIELD].
- Enqueue the traffic for output in the appropriate queue. The - Enqueue the traffic for output in the appropriate queue. The
scheduling of output from this queue may lead to shaping of the scheduling of output from this queue may lead to shaping of the
traffic or may simply cause it to be forwarded with some minimum traffic or may simply cause it to be forwarded with some minimum
rate or maximum latency assurance. rate or maximum latency assurance.
If the network is now built out of N-port routers, the expected behavior If the network is now built out of N-port routers, the expected behavior
of the network should be identical. Therefore, this model must provide of the network should be identical. Therefore, this model must provide
for essentially the same set of functions at the ingress as on the for essentially the same set of functions at the ingress as on the
egress of a router's interfaces. The one point of difference in the egress of a router's interfaces. The one point of difference in the
model between ingress and the egress is that all traffic at the egress model between ingress and the egress is that all traffic at the egress
skipping to change at page 10, line 38 skipping to change at page 10, line 49
queueing at the interface egress or may instead implement it only at the queueing at the interface egress or may instead implement it only at the
ingress. Furthermore, the classification needed to map a packet to an ingress. Furthermore, the classification needed to map a packet to an
egress queue (if present) need not be implemented at the egress but egress queue (if present) need not be implemented at the egress but
instead might be implemented at the ingress, with the packet passed instead might be implemented at the ingress, with the packet passed
through the routing core with in-band control information to allow for through the routing core with in-band control information to allow for
egress queue selection. egress queue selection.
Specifically, some interfaces will be at the outer "edge" and some will Specifically, some interfaces will be at the outer "edge" and some will
be towards the "core" of the Diffserv domain. It is to be expected (from be towards the "core" of the Diffserv domain. It is to be expected (from
the general principles guiding the motivation of Diffserv) that "edge" the general principles guiding the motivation of Diffserv) that "edge"
interfaces, or at least the routers that contain them, will contain more interfaces, or at least the routers that contain them, will implement
complexity and require more configuration than those in the core. more complexity and require more configuration than those in the core
although this is obviously not a requirement.
3.3. Shaping and Policing 3.3. Shaping and Policing
Diffserv nodes may apply shaping, policing and/or marking to traffic Diffserv nodes may apply shaping, policing and/or marking to traffic
streams that exceed the bounds of their TCS in order to prevent one streams that exceed the bounds of their TCS in order to prevent one
traffic stream from seizing more than its share of resources from a traffic stream from seizing more than its share of resources from a
Diffserv network. In this model, Shaping, sometimes considered as a TC Diffserv network. In this model, Shaping, sometimes considered as a TC
action, is treated as a function of queueing elements - see section 7. action, is treated as a function of queueing elements - see section 7.
Algorithmic Dropping techniques (e.g. RED) are similarly treated since Algorithmic Dropping techniques (e.g. RED) are similarly treated since
these often are closely associated with queues. Policing is modelled as these often are closely associated with queues. Policing is modelled as
skipping to change at page 12, line 25 skipping to change at page 12, line 38
classification keys used by the Classifier. This optimization may be classification keys used by the Classifier. This optimization may be
important for scalability in the management plane. Classifiers may also important for scalability in the management plane. Classifiers may also
be cascaded in sequence to perform more complex lookup operations whilst be cascaded in sequence to perform more complex lookup operations whilst
still maintaining such scalability. still maintaining such scalability.
Another example of a packet attribute could be an integer representing Another example of a packet attribute could be an integer representing
the BGP community string associated with the packet's best-matching the BGP community string associated with the packet's best-matching
route. Other contextual information may also be used by a Classifier route. Other contextual information may also be used by a Classifier
e.g. knowledge that a particular interface faces a Diffserv domain or a e.g. knowledge that a particular interface faces a Diffserv domain or a
legacy IPTOS domain [DSARCH] could be used when determining whether a legacy IPTOS domain [DSARCH] could be used when determining whether a
DSCP is present or not.
The following classifier separates traffic into one of three output
streams based on three filters:
Filter Matched Output Stream
-------------- ---------------
Filter1 A
Filter2 B
no match C
Where Filters1 and Filter2 are defined to be the following BA filters
([DSARCH], Section 4.2.1 ):
unclassified classified unclassified classified
traffic traffic traffic traffic
+------------+ +------------+
| |--> match Filter1 --> OutputA | |--> match Filter1 --> OutputA
------->| classifier |--> match Filter2 --> OutputB ------->| classifier |--> match Filter2 --> OutputB
| |--> no match --> OutputC | |--> no match --> OutputC
+------------+ +------------+
Figure 3. An Example Classifier Figure 3. An Example Classifier
DSCP is present or not.
The following BA classifier separates traffic into one of three output
streams based on matching filters:
Filter Matched Output Stream
-------------- ---------------
Filter1 A
Filter2 B
no match C
Where the filters are defined to be the following BA filters ([DSARCH],
Section 4.2.1 ):
Filter DSCP Filter DSCP
------ ------ ------ ------
1 101010 Filter1 101010
2 111111 Filter2 111111
3 ****** (wildcard) Filter3 ****** (wildcard)
4.1.1. Filters 4.1.1. Filters
A filter consists of a set of conditions on the component values of a A filter consists of a set of conditions on the component values of a
packet's classification key (the header values, contents, and attributes packet's classification key (the header values, contents, and attributes
relevant for classification). In the BA classifier example above, the relevant for classification). In the BA classifier example above, the
classification key consists of one packet header field, the DSCP, and classification key consists of one packet header field, the DSCP, and
both Filter1 and Filter2 specify exact-match conditions on the value of both Filter1 and Filter2 specify exact-match conditions on the value of
the DSCP. Filter3 is a wildcard default filter which matches every the DSCP. Filter3 is a wildcard default filter which matches every
packet, but which is only selected in the event that no other more packet, but which is only selected in the event that no other more
specific filter matches. specific filter matches.
In general there are a set of possible component conditions including In general there are a set of possible component conditions including
exact, prefix, range, masked and wildcard matches. Note that ranges can exact, prefix, range, masked and wildcard matches. Note that ranges can
be represented (with less efficiency) as a set of prefixes and that be represented (with less efficiency) as a set of prefixes and that
prefix matches are just a special case of both masked and range matches. prefix matches are just a special case of both masked and range matches.
In the case of a MF classifier [DSARCH], the classification key consists In the case of a MF classifier, the classification key consists of a
of a number of packet header fields. The filter may specify a different number of packet header fields. The filter may specify a different
condition for each key component, as illustrated in the example below condition for each key component, as illustrated in the example below
for a IPv4/TCP classifier: for a IPv4/TCP classifier:
Filter IPv4 Src Addr IPv4 Dest Addr TCP SrcPort TCP DestPort
------ ------------- -------------- ----------- ------------
Filter4 172.31.8.1/32 172.31.3.X/24 X 5003
In this example, the fourth octet of the destination IPv4 address and In this example, the fourth octet of the destination IPv4 address and
the source TCP port are wildcard or "don't care". the source TCP port are wildcard or "don't care".
MF classification of fragmented packets is impossible if the filter uses MF classification of IP-fragmented packets is impossible if the filter
transport-layer port numbers e.g. TCP port numbers. MTU-discovery is uses transport-layer port numbers e.g. TCP port numbers. MTU-discovery
therefore a prerequisite for proper operation of a Diffserv network that is therefore a prerequisite for proper operation of a Diffserv network
uses such classifiers. that uses such classifiers.
4.1.2. Overlapping Filters 4.1.2. Overlapping Filters
Note that it is easy to define sets of overlapping filters in a Note that it is easy to define sets of overlapping filters in a
classifier. For example: classifier. For example:
Filter IP Src Addr IP Dest Addr TCP SrcPort TCP DestPort Filter IPv4 Src Addr IPv4 Dest Addr
------ ------------- ------------- ----------- ------------ ------ ------------- --------------
Filter4 172.31.8.1/32 172.31.3.X/24 X 5003 Filter5 172.31.8.X/24 X/0
Filter5: Filter6 X/0 172.30.10.1/32
Type: Masked-DSCP
Value: 111000
Mask: 111000
Filter6:
Type: Masked-DSCP
Value: 000111 (binary)
Mask: 000111 (binary)
A packet containing DSCP = 111111 cannot be uniquely classified by this A packet containing {IP Dest Addr 172.31.8.1, IP Src Addr 172.30.10.1}
pair of filters and so a precedence must be established between Filter5 cannot be uniquely classified by this pair of filters and so a
and Filter6 in order to break the tie. This precedence must be precedence must be established between Filter5 and Filter6 in order to
established either (a) by a manager which knows that the router can break the tie. This precedence must be established either (a) by a
accomplish this particular ordering e.g. by means of reported manager which knows that the router can accomplish this particular
capabilities, or (b) by the router along with a mechanism to report to a ordering e.g. by means of reported capabilities, or (b) by the router
manager which precedence is being used. Such precedence mechanisms must along with a mechanism to report to a manager which precedence is being
be supported in any translation of this model into specific syntax for used. Such precedence mechanisms must be supported in any translation of
configuration and management protocols. this model into specific syntax for configuration and management
protocols.
As another example, one might want first to disallow certain As another example, one might want first to disallow certain
applications from using the network at all, or to classify some applications from using the network at all, or to classify some
individual traffic streams that are not Diffserv-marked. Traffic that is individual traffic streams that are not Diffserv-marked. Traffic that is
not classified by those tests might then be inspected for a DSCP. The not classified by those tests might then be inspected for a DSCP. The
word "then" implies sequence and this must be specified by means of word "then" implies sequence and this must be specified by means of
precedence. precedence.
An unambiguous classifier requires that every possible classification An unambiguous classifier requires that every possible classification
key match at least one filter (possibly the wildcard default) and that key match at least one filter (possibly the wildcard default) and that
skipping to change at page 17, line 33 skipping to change at page 17, line 34
Meters are logically 1:N (fan-out) devices (although a multiplexor can Meters are logically 1:N (fan-out) devices (although a multiplexor can
be used in front of a meter). Meters are parameterized by a temporal be used in front of a meter). Meters are parameterized by a temporal
profile and by conformance levels, each of which is associated with a profile and by conformance levels, each of which is associated with a
meter's output. Each output can be connected to another functional meter's output. Each output can be connected to another functional
element. element.
Note that this model of a meter differs slightly from that described in Note that this model of a meter differs slightly from that described in
[DSARCH]. In that description the meter is not a datapath element but is [DSARCH]. In that description the meter is not a datapath element but is
instead used to monitor the traffic stream and send control signals to instead used to monitor the traffic stream and send control signals to
action elements to dynamically modulate their behavior based on the action elements to dynamically modulate their behavior based on the
conformance of the packet. Figure 4 illustrates a meter with 3 levels of conformance of the packet. This difference in the description does not
conformance. change the function of a meter. Figure 4 illustrates a meter with 3
levels of conformance.
unmetered metered
traffic traffic
+---------+
| |--------> conformance A
--------->| meter |--------> conformance B
| |--------> conformance C
+---------+
Figure 4. A Generic Meter
In some Diffserv examples e.g. [AF-PHB], three levels of conformance are In some Diffserv examples e.g. [AF-PHB], three levels of conformance are
discussed in terms of colors, with green representing conforming, yellow discussed in terms of colors, with green representing conforming, yellow
representing partially conforming and red representing non-conforming. representing partially conforming and red representing non-conforming.
These different conformance levels may be used to trigger different These different conformance levels may be used to trigger different
queueing, marking or dropping treatment later on in the processing. queueing, marking or dropping treatment later on in the processing.
Other example meters use a binary notion of conformance; in the general Other example meters use a binary notion of conformance; in the general
case N levels of conformance can be supported. In general there is no case N levels of conformance can be supported. In general there is no
constraint on the type of functional datapath element following a meter constraint on the type of functional datapath element following a meter
output, but care must be taken not to inadvertently configure a datapath output, but care must be taken not to inadvertently configure a datapath
that results in packet reordering that is not consistent with the that results in packet reordering that is not consistent with the
requirements of the relevant PHB specification. requirements of the relevant PHB specification.
unmetered metered
traffic traffic
+---------+
| |--------> conformance A
--------->| meter |--------> conformance B
| |--------> conformance C
+---------+
Figure 4. A Generic Meter
A meter, according to this model, measures the rate at which packets A meter, according to this model, measures the rate at which packets
making up a stream of traffic pass it, compares the rate to some set of making up a stream of traffic pass it, compares the rate to some set of
thresholds and produces some number of potential results (two or more): thresholds and produces some number of potential results (two or more):
a given packet is said to be "conformant" to a level of the meter if, at a given packet is said to be "conformant" to a level of the meter if, at
the time that the packet is being examined, the stream appears to be the time that the packet is being examined, the stream appears to be
within the rate limit for the profile associated with that level. A within the rate limit for the profile associated with that level. A
fuller discussion of conformance to meter profiles (and the associated fuller discussion of conformance to meter profiles (and the associated
requirements that this places on the schedulers upstream) is provided in requirements that this places on the schedulers upstream) is provided in
Appendix A. Appendix A.
skipping to change at page 19, line 49 skipping to change at page 19, line 49
NonConformingOutput: AbsoluteDropper1 NonConformingOutput: AbsoluteDropper1
Profile2: Profile2:
Type: ExpWeightedMovingAvg Type: ExpWeightedMovingAvg
AverageRate: 25 kbps AverageRate: 25 kbps
Delta: 10 usec Delta: 10 usec
Gain: 1/16 Gain: 1/16
5.1.3. Two-Parameter Token Bucket Meter 5.1.3. Two-Parameter Token Bucket Meter
A more sophisticated Meter might measure loose conformance to a token A more sophisticated Meter might measure conformance to a token bucket
bucket (TB) profile (see above and Appendix A for discussions of loose (TB) profile. A TB profile generally has two parameters, an average
and strict conformance to a token bucket). A TB profile generally has token rate, R, and a burst size, B. TB Meters compare the arrival rate
two parameters, an average token rate and a burst size. TB Meters of packets to the average rate specified by the TB profile. Logically,
compare the arrival rate of packets to the average rate specified by the tokens accumulate in a bucket at the average rate, R, up to a maximum
TB profile. Logically, tokens accumulate in a bucket at the average credit which is the burst size, B. When a packet of length L arrives, a
rate, up to a maximum credit which is the burst size. Packets of length conformance test is applied. There are at least two such tests in
L bytes are considered conforming if any tokens are available in the widespread use:
bucket at the time of packet arrival: up to L bytes may then be borrowed
from future token allocations. Packets are allowed to exceed the average
rate in bursts up to the burst size. Packets which arrive to find a
bucket with no tokens in it are deemed non-conforming. A two-parameter
TB meter has exactly two possible conformance levels (conforming, non-
conforming). Note that "strict" conformance meters are also useful -
see e.g. [SRTCM] and [TRTCM].
A two-parameter TB meter might appear as follows: Strict conformance
Packets of length L bytes are considered conforming only if there
are sufficient tokens available in the bucket at the time of packet
arrival for the complete packet i.e. the current depth is greater
than or equal to L: no tokens may be borrowed from future token
allocations. For examples of this approach, see [SRTCM] and
[TRTCM].
Loose conformance
Packets of length L bytes are considered conforming if any tokens
are available in the bucket at the time of packet arrival: up to L
bytes may then be borrowed from future token allocations.
Packets are allowed to exceed the average rate in bursts up to the burst
size. For further discussion of loose and strict conformance to token
bucket profiles, as well as system and implementation issues, see
Appendix A.
A two-parameter TB meter has exactly two possible conformance levels
(conforming, non-conforming). Such a meter might appear as follows:
Meter3: Meter3:
Type: SimpleTokenBucket Type: SimpleTokenBucket
Profile: Profile3 Profile: Profile3
ConformanceType: loose
ConformingOutput: Queue1 ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper1 NonConformingOutput: AbsoluteDropper1
Profile3: Profile3:
Type: SimpleTokenBucket Type: SimpleTokenBucket
AverageRate: 200 kbps AverageRate: 200 kbps
BurstSize: 100 kbytes BurstSize: 100 kbytes
ConformanceType: loose
5.1.4. Multi-Stage Token Bucket Meter 5.1.4. Multi-Stage Token Bucket Meter
More complicated TB meters might define multiple burst sizes and more More complicated TB meters might define multiple burst sizes and more
conformance levels. Packets found to exceed the larger burst size are conformance levels. Packets found to exceed the larger burst size are
deemed non-conforming. Packets found to exceed the smaller burst size deemed non-conforming. Packets found to exceed the smaller burst size
are deemed partially conforming. Packets exceeding neither are deemed are deemed partially-conforming. Packets exceeding neither are deemed
conforming. Token bucket meters designed for Diffserv networks are conforming. Some token bucket meters designed for Diffserv networks are
described in more detail in [SRTCM, TRTCM, GTC]; in some of these described in more detail in [SRTCM, TRTCM]; in some of these references,
references, three levels of conformance are discussed in terms of colors
with green representing conforming, yellow representing partially three levels of conformance are discussed in terms of colors with green
conforming and red representing non-conforming. Note that these representing conforming, yellow representing partially conforming and
multiple-conformance-level meters can sometimes be implemented using an red representing non-conforming. Note that these multiple-conformance-
appropriate sequence of multiple two-parameter TB meters. level meters can sometimes be implemented using an appropriate sequence
of multiple two-parameter TB meters.
A profile for a multi-stage TB meter with three levels of conformance A profile for a multi-stage TB meter with three levels of conformance
might look as follows: might look as follows:
Meter4: Meter4:
Type: TwoRateTokenBucket Type: TwoRateTokenBucket
ProfileA: Profile4 ProfileA: Profile4
ConformanceTypeA: strict
ConformingOutputA: Queue1 ConformingOutputA: Queue1
ProfileB: Profile5 ProfileB: Profile5
ConformanceTypeB: strict
ConformingOutputB: Marker1 ConformingOutputB: Marker1
NonConformingOutput: AbsoluteDropper1 NonConformingOutput: AbsoluteDropper1
Profile4: Profile4:
Type: SimpleTokenBucket Type: SimpleTokenBucket
AverageRate: 100 kbps AverageRate: 100 kbps
BurstSize: 20 kbytes BurstSize: 20 kbytes
Profile5: Profile5:
Type: SimpleTokenBucket Type: SimpleTokenBucket
skipping to change at page 23, line 39 skipping to change at page 23, line 50
Output: Queue1 Output: Queue1
7. Queueing Elements 7. Queueing Elements
Queueing elements modulate the transmission of packets belonging to the Queueing elements modulate the transmission of packets belonging to the
different traffic streams and determine their ordering, possibly storing different traffic streams and determine their ordering, possibly storing
them temporarily or discarding them. Packets are usually stored either them temporarily or discarding them. Packets are usually stored either
because there is a resource constraint (e.g., available bandwidth) which because there is a resource constraint (e.g., available bandwidth) which
prevents immediate forwarding, or because the queueing block is being prevents immediate forwarding, or because the queueing block is being
used to alter the temporal properties of a traffic stream (i.e. used to alter the temporal properties of a traffic stream (i.e.
shaping). Packets are discarded either because of buffering limitations, shaping). Packets are discarded for one of the following reasons:
because a buffer threshold is exceeded (including when shaping is
performed), as a feedback control signal to reactive control protocols - because of buffering limitations.
such as TCP, because a meter exceeds a configured profile (i.e. - because a buffer threshold is exceeded (including when shaping
policing). is performed).
- as a feedback control signal to reactive control protocols such
as TCP.
- because a meter exceeds a configured profile (i.e. policing).
The queueing elements in this model represent a logical abstraction of a The queueing elements in this model represent a logical abstraction of a
queueing system, which is used to configure PHB-related parameters. The queueing system, which is used to configure PHB-related parameters. The
model can be used to represent a broad variety of possible model can be used to represent a broad variety of possible
implementations. However, it need not necessarily map one-to-one with implementations. However, it need not necessarily map one-to-one with
physical queueing systems in a specific router implementation. physical queueing systems in a specific router implementation.
Implementors should map the configurable parameters of the Implementors should map the configurable parameters of the
implementation's queueing systems to these queueing element parameters implementation's queueing systems to these queueing element parameters
as appropriate to achieve equivalent behaviors. as appropriate to achieve equivalent behaviors.
7.1. Queueing Model 7.1. Queueing Model
Queueing is a function which lends itself to innovation. It must be Queueing is a function which lends itself to innovation. It must be
modelled to allow a broad range of possible implementations to be modelled to allow a broad range of possible implementations to be
represented using common structures and parameters. This model uses represented using common structures and parameters. This model uses
functional decomposition as a tool to permit the needed lattitude. functional decomposition as a tool to permit the needed lattitude.
skipping to change at page 24, line 28 skipping to change at page 24, line 41
decomposes queueing into the component elements that perform each of decomposes queueing into the component elements that perform each of
these functions: Queues, Schedulers and Algorithmic Droppers, these functions: Queues, Schedulers and Algorithmic Droppers,
respectively. These elements may be connected together as part of a respectively. These elements may be connected together as part of a
TCB, as described in section 8. TCB, as described in section 8.
The remainder of this section discusses FIFO Queues: typically, the The remainder of this section discusses FIFO Queues: typically, the
Queue element of this model will be implemented as a FIFO data Queue element of this model will be implemented as a FIFO data
structure. However, this does not preclude implementations which are not structure. However, this does not preclude implementations which are not
strictly FIFO, in that they also support operations that remove or strictly FIFO, in that they also support operations that remove or
examine packets (e.g., for use by discarders) other than at the head or examine packets (e.g., for use by discarders) other than at the head or
tail. However, such operations MUST NOT have the effect of reordering tail. However, such operations must not have the effect of reordering
packets belonging to the same microflow. packets belonging to the same microflow.
Note that the term FIFO has multiple different common usages: it is Note that the term FIFO has multiple different common usages: it is
sometimes taken to mean, among other things, a data structure that sometimes taken to mean, among other things, a data structure that
permits items to be removed only in the order in which they were permits items to be removed only in the order in which they were
inserted or a service discipline which is non-reordering. inserted or a service discipline which is non-reordering.
7.1.1. FIFO Queue 7.1.1. FIFO Queue
In this model, a FIFO Queue element is a data structure which at any In this model, a FIFO Queue element is a data structure which at any
skipping to change at page 28, line 4 skipping to change at page 28, line 23
Input3: Input3:
MaxRateProfile: WorkConserving MaxRateProfile: WorkConserving
MinRateProfile: none MinRateProfile: none
Priority: 3 Priority: 3
7.1.3. Algorithmic Dropper 7.1.3. Algorithmic Dropper
An Algorithmic Dropper is an element which selectively discards packets An Algorithmic Dropper is an element which selectively discards packets
that arrive at its input, based on a discarding algorithm. It has one that arrive at its input, based on a discarding algorithm. It has one
data input and one output. In this model (but not necessarily in a real data input and one output. In this model (but not necessarily in a real
implementation), a packet enters the dropper at its input and either its implementation), a packet enters the dropper at its input and either its
buffer is returned to a free buffer pool or the packet exits the dropper buffer is returned to a free buffer pool or the packet exits the dropper
at the output. at the output.
Alternatively, an Algorithmic Dropper can be thought of as invoking Alternatively, an Algorithmic Dropper can be thought of as invoking
operations on a FIFO which selectively remove a packet and return its operations on a FIFO Queue which selectively remove a packet and return
buffer to the free buffer pool based on a discarding algorithm. In this its buffer to the free buffer pool based on a discarding algorithm. In
case, the operation could be modelled as being a side-effect on the FIFO this case, the operation could be modelled as being a side-effect on the
upon which it operated, rather than as having a discrete input and FIFO upon which it operated, rather than as having a discrete input and
output. This treatment is equivalent and we choose the one described in output. This treatment is equivalent and we choose the one described in
the previous paragraph for this model. the previous paragraph for this model.
One of the primary characteristics of an Algorithmic Dropper is the
choice of which packet is to be dropped, if any: for the purposes of
this model, we restrict the packet selection choices to one of the
following and we indicate the choice by the relative positions of
Algorithmic Dropper and FIFO Queue elements in the model:
a) selection of a packet that is about to be added to the tail of a
queue (a "Tail Dropper"): the output of the Algorithmic Dropper
element is connected to the input of the relevant FIFO Queue
element.
b) a packet that is currently at the head of a queue (a "Head
Dropper"): the output of the FIFO Queue element is connected to the
input of the Algorithmic Dropper element.
Other packet selection methods could be added to this model in the form
of a different type of datapath element.
The Algorithmic Dropper is modelled as having a single input. It is The Algorithmic Dropper is modelled as having a single input. It is
possible that packets which were classified differently by a Classifier possible that packets which were classified differently by a Classifier
in this TCB will end up passing through the same dropper. The dropper's in this TCB will end up passing through the same dropper. The dropper's
algorithm may need to apply different calculations based on algorithm may need to apply different calculations based on
characteristics of the incoming packet e.g. its DSCP. So there is a characteristics of the incoming packet e.g. its DSCP. So there is a
need, in implementations of this model, to be able to relate information need, in implementations of this model, to be able to relate information
about which classifier element was matched by a packet from a Classifier about which classifier element was matched by a packet from a Classifier
to an Algorithmic Dropper. In the rare cases where this is required, to an Algorithmic Dropper. In the rare cases where this is required,
the chosen model is to insert another Classifier element at this point the chosen model is to insert another Classifier element at this point
in the flow and for it to feed into multiple Algorithmic Dropper in the flow and for it to feed into multiple Algorithmic Dropper
skipping to change at page 28, line 50 skipping to change at page 29, line 40
leading eventually back to the Classifier elements that matched the leading eventually back to the Classifier elements that matched the
packet. Yet another formulation might have been for the Classifier packet. Yet another formulation might have been for the Classifier
to (logically) include some sort of "classification identifier" to (logically) include some sort of "classification identifier"
along with the packet along its path, for use by any subsequent along with the packet along its path, for use by any subsequent
element. And yet another could have been to include a classifier element. And yet another could have been to include a classifier
inside the dropper, in order for it to pick out the drop algorithm inside the dropper, in order for it to pick out the drop algorithm
to be applied. These other approaches could be used by to be applied. These other approaches could be used by
implementations but were deemed to be less clear than the approach implementations but were deemed to be less clear than the approach
taken here. taken here.
An Algorithmic Dropper, illustrated in Figure 5, has one or more An Algorithmic Dropper, an example of which illustrated in Figure 5, has
triggers that cause it to make a decision whether or not to drop one (or one or more triggers that cause it to make a decision whether or not to
drop one (or possibly more than one) packet. A trigger may be internal
possibly more than one) packet. A trigger may be internal (the arrival (the arrival of a packet at the input to the dropper) or it may be
of a packet at the input to the dropper) or it may be external external (resulting from one or more state changes at another element,
(resulting from one or more state changes at another element, such as a such as a FIFO Queue depth crossing a threshold or a scheduling event).
FIFO depth crossing a threshold or a scheduling event). It is likely It is likely that an instantaneous FIFO depth will need to be smoothed
that an instantaneous FIFO depth will need to be smoothed over some over some averaging interval before being used as a useful trigger. Some
averaging interval. Some dropping algorithms may require several trigger dropping algorithms may require several trigger inputs feeding back from
inputs feeding back from events elsewhere in the system e.g. depth- events elsewhere in the system e.g. depth-smoothing functions that
smoothing functions that calculate averages over more than one time calculate averages over more than one time interval.
interval. Smoothing functions are outside the scope of this document
and are not modelled here, we merely indicate where they might be added
in the model.
A trigger may be a boolean combination of events (e.g. a FIFO depth +------------------+ +-----------+
exceeding a threshold OR a buffer pool depth falling below a threshold). | +-------+ | n |smoothing |
| |trigger|<----------/---|function(s)|
| |calc. | | |(optional) |
| +-------+ | +-----------+
| | | ^
| v | |Depth
Input | +-------+ no | ------------+ to Scheduler
---------->|discard|--------------> |x|x|x|x|------->
| | ? | | ------------+
| +-------+ | FIFO
| |yes |
| | | | |
| | v | count + |
| +---+ bit-bucket|
+------------------+
Algorithmic
Dropper
The dropping algorithm makes a decision on whether to forward or to Figure 5. Example of Algorithmic Dropper from Tail of a Queue
discard a packet and, if discarding, whether to discard it from the
head, tail or other part of the associated queue. It takes as its
parameters some set of dynamic parameters e.g. smoothed or instantaneous
+--------------------------------------+ A trigger may be a boolean combination of events e.g. a FIFO depth
| +------------+ +-----------+ |Algorithmic exceeding a threshold OR a buffer pool depth falling below a threshold.
| | smoothing | n |trigger & | |Dropper It takes as its input some set of dynamic parameters e.g. smoothed or
| | function(s)|---/--->|discard | | instantaneous FIFO depth and some set of static parameters e.g.
| | (optional) | |calc. | | thresholds, and possibly other parameters associated with the packet. It
| +------------+ +-----------+ | may also have internal state e.g. history of its past actions. Note
| ^ TailDrop| |HeadDrop | that, although an Algorithmic Dropper may require knowledge of data
+------------|-------------|-|---------+ fields in a packet, as discovered by a Classifier in the same TCB, it
| | | may not modify the packet (i.e. it is not a marker).
+---|-------------+ |
| | |
v |Depth v
Input ----------------------+ Output
-----------------------------> |x|x|x|x|x|x|x|------------------->
----------------------+
FIFO |
|
| | |
| v | bit-bucket
+---+
Figure 5. Algorithmic Dropper + Queue The result of the trigger calculation is that the dropping algorithm
makes a decision on whether to forward or to discard a packet. The
discarding function is likely to keep counters regarding the discarded
packets (there is no appropriate place here to include a Counter Action
element).
FIFO depth, some set of static parameters e.g. thresholds, and possibly The example in Figure 5 also shows a FIFO Queue element from whose tail
other parameters associated with the packet. It may also have internal the dropping is to take place and whose depth characteristics are used
state and is likely to keep counters regarding the dropped packets by this Algorithmic Dropper. It also shows where a depth-smoothing
(there is no appropriate place here to include a Counter Action function might be included: smoothing functions are outside the scope of
element). Note that, although an Algorithmic Dropper may require this document and are not modelled explicitly here, we merely indicate
knowledge of data fields in a packet, as discovered by a Classifier in where they might be added.
the same TCB, it may not modify the packet (i.e. it is not a marker).
RED, RED-on-In-and-Out (RIO) and Drop-on-threshold are examples of RED, RED-on-In-and-Out (RIO) and Drop-on-threshold are examples of
dropping algorithms. Tail-dropping and head-dropping are effected by the dropping algorithms. Tail-dropping and head-dropping are effected by the
location of the dropper relative to the FIFO. location of the Algorithmic Dropper element relative to the FIFO Queue
element. As an example, a dropper using a RIO algorithm might be
For example, a dropper using a RIO algorithm might be represented using represented using 2 Algorithmic Droppers with the following parameters:
2 Algorithmic Droppers with the following parameters:
AlgorithmicDropper1: (for in-profile traffic) AlgorithmicDropper1: (for in-profile traffic)
Type: AlgorithmicDropper Type: AlgorithmicDropper
Discipline: RED, discard from tail Discipline: RED
Trigger: Internal Trigger: Internal
Output: Fifo1 Output: Fifo1
MinThresh: Fifo1.Depth > 20 kbyte MinThresh: Fifo1.Depth > 20 kbyte
MaxThresh: Fifo1.Depth > 30 kbyte MaxThresh: Fifo1.Depth > 30 kbyte
SampleWeight .002 SampleWeight .002
MaxDropProb 1% MaxDropProb 1%
AlgorithmicDropper2: (for out-of-profile traffic) AlgorithmicDropper2: (for out-of-profile traffic)
Type: AlgorithmicDropper Type: AlgorithmicDropper
Discipline: RED, discard from tail Discipline: RED
Trigger: Internal Trigger: Internal
Output: Fifo1 Output: Fifo1
MinThresh: Fifo1.Depth > 10 kbyte MinThresh: Fifo1.Depth > 10 kbyte
MaxThresh: Fifo1.Depth > 20 kbyte MaxThresh: Fifo1.Depth > 20 kbyte
SampleWeight .002 SampleWeight .002
MaxDropProb 2% MaxDropProb 2%
Another form of Algorithmic Dropper, a threshold-dropper, might be Another form of Algorithmic Dropper, a threshold-dropper, might be
represented using the following parameters: represented using the following parameters:
AlgorithmicDropper3: AlgorithmicDropper3:
Type: AlgorithmicDropper Type: AlgorithmicDropper
Discipline: Drop-on-threshold, discard from tail Discipline: Drop-on-threshold
Trigger: Fifo2.Depth > 20 kbyte Trigger: Fifo2.Depth > 20 kbyte
Output: Fifo1 Output: Fifo1
7.2. Sharing load among traffic streams using queueing 7.2. Sharing load among traffic streams using queueing
Queues are used, in Differentiated Services, for a number of purposes. Queues are used, in Differentiated Services, for a number of purposes.
In essence, they are simply places to store traffic until it is In essence, they are simply places to store traffic until it is
transmitted. However, when several queues are used together in a transmitted. However, when several queues are used together in a
queueing system, they can also achieve effects beyond that for given queueing system, they can also achieve effects beyond that for given
traffic streams. They can be used to limit variation in delay or impose traffic streams. They can be used to limit variation in delay or impose
skipping to change at page 31, line 34 skipping to change at page 32, line 23
conserving Scheduler. Some implementations may elect to have queues conserving Scheduler. Some implementations may elect to have queues
whose sole purpose is shaping, while others may integrate the shaping whose sole purpose is shaping, while others may integrate the shaping
function with other buffering, discarding and scheduling associated with function with other buffering, discarding and scheduling associated with
access to a resource. Shapers operate by delaying the departure of access to a resource. Shapers operate by delaying the departure of
packets that would be deemed non-conforming by a meter configured to the packets that would be deemed non-conforming by a meter configured to the
shaper's maximum service rate profile. The packet is scheduled to depart shaper's maximum service rate profile. The packet is scheduled to depart
no sooner than such time that it would become conforming. no sooner than such time that it would become conforming.
7.2.1. Load Sharing 7.2.1. Load Sharing
Load sharing is the traditional use of queues. It was theoretically Load sharing is the traditional use of queues and was theoretically
explored in a paper by Floyd [FLOYD] in 1993, but has been in use in explored by Floyd & Jacobson [FJ95] although it has been in use in
communications systems since the 1970's. communications systems since the 1970's.
[DSARCH] discusses load sharing as dividing an interface among traffic [DSARCH] discusses load sharing as dividing an interface among traffic
classes predictably or applying a minimum rate to each of a set of classes predictably or applying a minimum rate to each of a set of
traffic classes, which might be measured as an absolute lower bound on traffic classes, which might be measured as an absolute lower bound on
the rate a traffic stream achieves or a fraction of the rate an the rate a traffic stream achieves or a fraction of the rate an
interface offers. It is generally implemented as some form of weighted interface offers. It is generally implemented as some form of weighted
queueing algorithm among a set of FIFO queues i.e. a WFQ scheme. This queueing algorithm among a set of FIFO queues i.e. a WFQ scheme. This
has interesting side-effects. has interesting side-effects.
skipping to change at page 34, line 32 skipping to change at page 35, line 23
elements are allowed: elements are allowed:
1) The input of a Queue may be the input of the queueing block or it 1) The input of a Queue may be the input of the queueing block or it
may be connected to the output of an Algorithmic Dropper or to an may be connected to the output of an Algorithmic Dropper or to an
output of a Scheduler. output of a Scheduler.
2) Each input of a Scheduler may be connected to the output of a 2) Each input of a Scheduler may be connected to the output of a
Queue, to the output of an Algorithmic Dropper or to the output of Queue, to the output of an Algorithmic Dropper or to the output of
another Scheduler. another Scheduler.
3) The input of an Algorithmic Dropper must be the first element of 3) The input of an Algorithmic Dropper may be the first element of the
the queueing stage, the output of another Algorithmic Dropper. queueing stage, the output of another Algorithmic Dropper or it may
be connected to the output of a Queue (to indicate head-dropping).
4) The output of the queueing block may be the output of a Queue, an 4) The output of the queueing block may be the output of a Queue, an
Algorithmic Dropper or a Scheduler. Algorithmic Dropper or a Scheduler.
Note, in particular, that Schedulers may operate in series such that a Note, in particular, that Schedulers may operate in series such that a
packet at the head of a Queue feeding the concatenated Schedulers is packet at the head of a Queue feeding the concatenated Schedulers is
serviced only after all of the scheduling criteria are met. For example, serviced only after all of the scheduling criteria are met. For example,
a Queue which carries EF traffic streams may be served first by a non- a Queue which carries EF traffic streams may be served first by a non-
work-conserving Scheduler to shape the stream to a maximum rate, then by work-conserving Scheduler to shape the stream to a maximum rate, then by
a work-conserving Scheduler to mix EF traffic streams with other traffic a work-conserving Scheduler to mix EF traffic streams with other traffic
streams. Alternatively, there might be a Queue and/or a dropper between streams. Alternatively, there might be a Queue and/or a dropper between
the two Schedulers. the two Schedulers.
Note also that some non-sensical scenarios e.g. a Queue preceding an
Algorithmic Dropper, directly feeding into another Queue, are
prohibited.
8.2. An Example TCB 8.2. An Example TCB
A SLS is presumed to have been negotiated between the customer and the A SLS is presumed to have been negotiated between the customer and the
provider which specifies the handling of the customer's traffic, as provider which specifies the handling of the customer's traffic, as
defined by a TCS) by the provider's network. The agreement might be of defined by a TCS) by the provider's network. The agreement might be of
the following form: the following form:
DSCP PHB Profile Treatment DSCP PHB Profile Treatment
---- --- ------- ---------------------- ---- --- ------- ----------------------
001001 EF Profile4 Discard non-conforming. 001001 EF Profile4 Discard non-conforming.
001100 AF11 Profile5 Shape to profile, tail-drop when full. 001100 AF11 Profile5 Shape to profile, tail-drop when full.
001101 AF21 Profile3 Re-mark non-conforming to DSCP 001000, 001101 AF21 Profile3 Re-mark non-conforming to DSCP 001000,
tail-drop when full. tail-drop when full.
other BE none Apply RED-like dropping. other BE none Apply RED-like dropping.
skipping to change at page 36, line 5 skipping to change at page 36, line 47
two conformance levels: conforming or non-conforming. two conformance levels: conforming or non-conforming.
Following the Metering stage is an Action stage in some of the branches. Following the Metering stage is an Action stage in some of the branches.
Packets submitted for DSCP 001001 (Classifier output A) that are deemed Packets submitted for DSCP 001001 (Classifier output A) that are deemed
non-conforming by Meter1 are counted and discarded while packets that non-conforming by Meter1 are counted and discarded while packets that
are conforming are passed on to Queue1. Packets submitted for DSCP are conforming are passed on to Queue1. Packets submitted for DSCP
001101 (Classifier output C) that are deemed non-conforming by Meter2 001101 (Classifier output C) that are deemed non-conforming by Meter2
are re-marked and then both conforming and non-conforming packets are are re-marked and then both conforming and non-conforming packets are
multiplexed together before being passed on to Dropper2/Queue3. multiplexed together before being passed on to Dropper2/Queue3.
The Algorithmic Dropping, Queueing and Scheduling stages are realised as
follows, illustrated in figure 7. Note that the figure does not show any
of the implicit control linkages between elements that allow e.g. an
Algorithmic Dropper to sense the current state of a succeeding Queue.
+-----+ +-----+
| A|---------------------------> to Queue1 | A|---------------------------> to Queue1
+->| | +->| |
| | B|--+ +-----+ +-----+ | | B|--+ +-----+ +-----+
| +-----+ | | | | | | +-----+ | | | | |
| Meter1 +->| |--->| | | Meter1 +->| |--->| |
| | | | | | | | | |
| +-----+ +-----+ | +-----+ +-----+
| Counter1 Absolute | Counter1 Absolute
submitted +-----+ | Dropper1 submitted +-----+ | Dropper1
skipping to change at page 36, line 32 skipping to change at page 37, line 32
| | B|--+ +-----+ +->|B | | | B|--+ +-----+ +->|B |
| +-----+ | | | | +-----+ | +-----+ | | | | +-----+
| Meter2 +->| |-+ Mux1 | Meter2 +->| |-+ Mux1
| | | | | |
| +-----+ | +-----+
| Marker1 | Marker1
+-----------------------------------> to AlgDropper3 +-----------------------------------> to AlgDropper3
Figure 6: An Example Traffic Conditioning Block (Part 1) Figure 6: An Example Traffic Conditioning Block (Part 1)
The Algorithmic Dropping, Queueing and Scheduling stages are realised as
follows, illustrated in figure 7. Note that the figure does not show any
of the implicit control linkages between elements that allow e.g. an
Algorithmic Dropper to sense the current state of a succeeding Queue.
Conforming DSCP 001001 packets from Meter1 are passed directly to Conforming DSCP 001001 packets from Meter1 are passed directly to
Queue1: there is no way, with configuration of the following Scheduler Queue1: there is no way, with configuration of the following Scheduler
to match the metering, for these packets to overflow the depth of Queue1 to match the metering, for these packets to overflow the depth of Queue1
so there is no requirement for dropping at this point. Packets marked so there is no requirement for dropping at this point. Packets marked
for DSCP 001100 must be passed through a tail-dropper, AlgDropper1, for DSCP 001100 must be passed through a tail-dropper, AlgDropper1,
which serves to limit the depth of the following queue, Queue2: packets which serves to limit the depth of the following queue, Queue2: packets
that arrive to a full queue will be discarded. This is likely to be an that arrive to a full queue will be discarded. This is likely to be an
error case: the customer is obviously not sticking to its agreed error case: the customer is obviously not sticking to its agreed
profile. Similarly, all packets from the original DSCP 001101 stream profile. Similarly, all packets from the original DSCP 001101 stream
(some may have been re-marked by this stage) are passed to AlgDropper2 (some may have been re-marked by this stage) are passed to AlgDropper2
skipping to change at page 37, line 22 skipping to change at page 38, line 19
than the other queues, appropriate for its best-effort status. Traffic than the other queues, appropriate for its best-effort status. Traffic
then exits the Scheduler in a single orderly stream. then exits the Scheduler in a single orderly stream.
The interconnections of the TCB elements illustrated in Figures 6 and 7 The interconnections of the TCB elements illustrated in Figures 6 and 7
can be represented textually as follows: can be represented textually as follows:
TCB1: TCB1:
Classifier1: Classifier1:
FilterA: Meter1 FilterA: Meter1
FilterB: Dropper1
FilterC: Meter2
Default: Dropper3
from Meter1 +-----+ from Meter1 +-----+
------------------------------->| |----+ ------------------------------->| |----+
| | | | | |
+-----+ | +-----+ |
Queue1 | Queue1 |
| +-----+ | +-----+
from Classifier1 +-----+ +-----+ +->|A | from Classifier1 +-----+ +-----+ +->|A |
---------------->| |------->| |------>|B |-------> ---------------->| |------->| |------>|B |------->
| | | | +--->|C | exiting | | | | +--->|C | exiting
skipping to change at page 38, line 4 skipping to change at page 39, line 4
+-----+ +-----+ | +-----+ +-----+ |
AlgDropper2 Queue3 | AlgDropper2 Queue3 |
| |
from Classifier1 +-----+ +-----+ | from Classifier1 +-----+ +-----+ |
---------------->| |------->| |----+ ---------------->| |------->| |----+
| | | | | | | |
+-----+ +-----+ +-----+ +-----+
AlgDropper3 Queue4 AlgDropper3 Queue4
Figure 7: An Example Traffic Conditioning Block (Part 2) Figure 7: An Example Traffic Conditioning Block (Part 2)
FilterB: Dropper1
FilterC: Meter2
Default: Dropper3
Meter1: Meter1:
Type: AverageRate Type: AverageRate
Profile: Profile4 Profile: Profile4
ConformingOutput: Queue1 ConformingOutput: Queue1
NonConformingOutput: Counter1 NonConformingOutput: Counter1
Counter1: Counter1:
Output: AbsoluteDropper1 Output: AbsoluteDropper1
Meter2: Meter2:
skipping to change at page 40, line 38 skipping to change at page 41, line 33
(as defined above) (as defined above)
TCB2: TCB2:
(similar to TCB1, perhaps with different (similar to TCB1, perhaps with different
elements or numeric parameters) elements or numeric parameters)
TCB3: TCB3:
(similar to TCB1, perhaps with different (similar to TCB1, perhaps with different
elements or numeric parameters) elements or numeric parameters)
and the filters, based on each customer's source MAC address, could be
defined as follows:
Filter1:
submitted +-----+ submitted +-----+
traffic | A|--------> TCB1 traffic | A|--------> TCB1
--------->| B|--------> TCB2 --------->| B|--------> TCB2
| C|--------> TCB3 | C|--------> TCB3
| X|------+ +-----+ | X|------+ +-----+
+-----+ +-->| | +-----+ +-->| |
Classifier4 +-----+ Classifier4 +-----+
AbsoluteDrop4 AbsoluteDrop4
Figure 8: An Example of a Multi-Customer TCB Figure 8: An Example of a Multi-Customer TCB
and the filters, based on each customer's source MAC address, could be
defined as follows:
Filter1:
Type: MacAddress Type: MacAddress
SrcValue: 01-02-03-04-05-06 (source MAC address of customer 1) SrcValue: 01-02-03-04-05-06 (source MAC address of customer 1)
SrcMask: FF-FF-FF-FF-FF-FF SrcMask: FF-FF-FF-FF-FF-FF
DestValue: 00-00-00-00-00-00 DestValue: 00-00-00-00-00-00
DestMask: 00-00-00-00-00-00 DestMask: 00-00-00-00-00-00
Filter2: Filter2:
(similar to Filter1 but with customer 2's source MAC address as (similar to Filter1 but with customer 2's source MAC address as
SrcValue) SrcValue)
skipping to change at page 42, line 4 skipping to change at page 42, line 47
additional functionality to the customer. It recognizes individual additional functionality to the customer. It recognizes individual
customer microflows and marks each one independently. It also isolates customer microflows and marks each one independently. It also isolates
the customer's individual microflows from each other in order to prevent the customer's individual microflows from each other in order to prevent
a single microflow from seizing an unfair share of the resources a single microflow from seizing an unfair share of the resources
available to the customer at a certain service level. This is available to the customer at a certain service level. This is
illustrated in Figure 9. illustrated in Figure 9.
Suppose that the customer has an SLS which specifices 2 service levels, Suppose that the customer has an SLS which specifices 2 service levels,
to be identifed to the provider by DSCP A and DSCP B. Traffic is first to be identifed to the provider by DSCP A and DSCP B. Traffic is first
directed to a MF classifier which classifies traffic based on directed to a MF classifier which classifies traffic based on
miscellaneous classification criteria, to a granularity sufficient to
identify individual customer microflows. Each microflow can then be
marked for a specific DSCP The metering elements limit the contribution
of each of the customer's microflows to the service level for which it
+-----+ +-----+ +-----+ +-----+
Classifier1 | | | |---------------+ Classifier1 | | | |---------------+
(MF) +->| |-->| | +-----+ | (MF) +->| |-->| | +-----+ |
+-----+ | | | | |---->| | | +-----+ | | | | |---->| | |
| A|------ +-----+ +-----+ +-----+ | | A|------ +-----+ +-----+ +-----+ |
--->| B|-----+ Marker1 Meter1 Absolute | --->| B|-----+ Marker1 Meter1 Absolute |
| C|---+ | Dropper1 | +-----+ | C|---+ | Dropper1 | +-----+
| X|-+ | | +-----+ +-----+ +-->|A | | X|-+ | | +-----+ +-----+ +-->|A |
+-----+ | | | | | | |------------------>|B |---> +-----+ | | | | | | |------------------>|B |--->
| | +->| |-->| | +-----+ +-->|C | to TCB2 | | +->| |-->| | +-----+ +-->|C | to TCB2
skipping to change at page 42, line 29 skipping to change at page 43, line 29
| | | | | |---------------+ | | | | | |---------------+
| |--->| |-->| | +-----+ | |--->| |-->| | +-----+
| | | | |---->| | | | | | |---->| |
| +-----+ +-----+ +-----+ | +-----+ +-----+ +-----+
| Marker3 Meter3 Absolute | Marker3 Meter3 Absolute
| Dropper3 | Dropper3
V etc. V etc.
Figure 9: An Example of a Marking and Traffic Isolation TCB Figure 9: An Example of a Marking and Traffic Isolation TCB
miscellaneous classification criteria, to a granularity sufficient to
identify individual customer microflows. Each microflow can then be
marked for a specific DSCP The metering elements limit the contribution
of each of the customer's microflows to the service level for which it
was marked. Packets exceeding the allowable limit for the microflow are was marked. Packets exceeding the allowable limit for the microflow are
dropped. dropped.
This TCB could be formally specified as follows: This TCB could be formally specified as follows:
TCB1: TCB1:
Classifier1: (MF) Classifier1: (MF)
FilterA: Marker1 FilterA: Marker1
FilterB: Marker2 FilterB: Marker2
FilterC: Marker3 FilterC: Marker3
skipping to change at page 43, line 32 skipping to change at page 44, line 26
etc. etc.
Mux1: Mux1:
Output: to TCB2 Output: to TCB2
Note that the detailed traffic element declarations are not shown here. Note that the detailed traffic element declarations are not shown here.
Traffic is either dropped by TCB1 or emerges marked for one of two Traffic is either dropped by TCB1 or emerges marked for one of two
DSCPs. This traffic is then passed to TCB2 which is illustrated in DSCPs. This traffic is then passed to TCB2 which is illustrated in
Figure 10. Figure 10.
TCB2 could then be specified as follows:
Classifier2: (BA)
FilterA: Meter5
FilterB: Meter6
+-----+ +-----+
| |---------------> to Queue1 | |---------------> to Queue1
+->| | +-----+ +->| | +-----+
+-----+ | | |---->| | +-----+ | | |---->| |
| A|---+ +-----+ +-----+ | A|---+ +-----+ +-----+
->| | Meter5 AbsoluteDropper4 ->| | Meter5 AbsoluteDropper4
| B|---+ +-----+ | B|---+ +-----+
+-----+ | | |---------------> to Queue2 +-----+ | | |---------------> to Queue2
Classifier2 +->| | +-----+ Classifier2 +->| | +-----+
(BA) | |---->| | (BA) | |---->| |
+-----+ +-----+ +-----+ +-----+
Meter6 AbsoluteDropper5 Meter6 AbsoluteDropper5
Figure 10: Additional Example: TCB2 Figure 10: Additional Example: TCB2
TCB2 could then be specified as follows:
Classifier2: (BA)
FilterA: Meter5
FilterB: Meter6
Meter5: Meter5:
ConformingOutput: Queue1 ConformingOutput: Queue1
NonConformingOutput: AbsoluteDropper4 NonConformingOutput: AbsoluteDropper4
Meter6: Meter6:
ConformingOutput: Queue2 ConformingOutput: Queue2
NonConformingOutput: AbsoluteDropper5 NonConformingOutput: AbsoluteDropper5
8.5. Cascaded TCBs 8.5. Cascaded TCBs
skipping to change at page 45, line 17 skipping to change at page 46, line 17
Security vulnerabilities of Diffserv network operation are discussed in Security vulnerabilities of Diffserv network operation are discussed in
[DSARCH]. This document describes an abstract functional model of [DSARCH]. This document describes an abstract functional model of
Diffserv router elements. Certain denial-of-service attacks such as Diffserv router elements. Certain denial-of-service attacks such as
those resulting from resource starvation may be mitigated by appropriate those resulting from resource starvation may be mitigated by appropriate
configuration of these router elements; for example, by rate limiting configuration of these router elements; for example, by rate limiting
certain traffic streams or by authenticating traffic marked for higher certain traffic streams or by authenticating traffic marked for higher
quality-of-service. quality-of-service.
One particular theft- or denial-of-service issue may arise where a One particular theft- or denial-of-service issue may arise where a
token-bucket meter, with an absolute dropper for non-conforming traffic, token-bucket meter, with an absolute dropper for non-conforming traffic,
is used in a TCB to police a stream to a given TCS: the definition of is used in a TCB to police a stream to a given TCS: suppose that the
the token-bucket meter in section 5 indicates that it should be lenient leaky-bucket scheduler that sent the packet was being conservative in
in accepting a packet whenever any bits of the packet would have been that it only transmitted the packet if the whole packet fitted within
within the profile; the definition of the leaky-bucket scheduler is the profile; suppose further that the token-bucket meter is using a
conservative in that a packet is to be transmitted only if the whole "loose" conformance test, as described in section 5, and indicates that
packet fits within the profile. This difference may be exploited by a it should accept this packet even though not all of the bits would have
malicious scheduler either to obtain QoS treatment for more octets than been within the profile: this difference may be exploited by a malicious
allowed in the TCS or to disrupt (perhaps only slightly) the QoS scheduler either to obtain QoS treatment for more octets than allowed in
guarantees promised to other traffic streams. the TCS or to disrupt (perhaps only slightly) the QoS guarantees
promised to other traffic streams.
10. Acknowledgments 10. Acknowledgments
Concepts, terminology, and text have been borrowed liberally from Concepts, terminology, and text have been borrowed liberally from
[POLTERM], as well as from other IETF work on MIBs and policy- [POLTERM], as well as from other IETF work on MIBs and policy-
management. We wish to thank the authors of some of those documents: management. We wish to thank the authors of some of those documents:
Fred Baker, Michael Fine, Keith McCloghrie, John Seligson, Kwok Chan, Fred Baker, Michael Fine, Keith McCloghrie, John Seligson, Kwok Chan,
Scott Hahn and Andrea Westerinen for their contributions. Scott Hahn and Andrea Westerinen for their contributions.
This document has benefitted from the comments and suggestions of This document has benefitted from the comments and suggestions of
several participants of the Diffserv working group, particularly John several participants of the Diffserv working group, particularly Shahram
Strassner and Walter Weiss. Davari, John Strassner and Walter Weiss. This document could never have
reached this level of rough consensus without the relentless pressure of
the co-chairs Brian Carpenter and Kathie Nichols, for which the authors
are grateful.
11. References 11. References
[AF-PHB] [AF-PHB]
J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, "Assured J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999. Forwarding PHB Group", RFC 2597, June 1999.
[DSARCH] [DSARCH]
M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and E. Davies, M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and E. Davies,
"An Architecture for Differentiated Services", RFC 2475, December "An Architecture for Differentiated Services", RFC 2475, December
1998 1998
[DSFIELD] [DSFIELD]
K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998. Headers", RFC 2474, December 1998.
[DSMIB] [DSMIB]
F. Baker, A. Smith, K. Chan, "Differentiated Services MIB", F. Baker, A. Smith, K. Chan, "Differentiated Services MIB",
Internet Draft <http://www.ietf.org/internet-drafts/draft-ietf- Internet Draft <http://www.ietf.org/internet-drafts/draft-ietf-
diffserv-mib-05.txt>, November 2000. diffserv-mib-06.txt>, January 2001.
[E2E] [E2E]
Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer, K. Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, M. Speer, K.
Nichols, R. Braden, B. Davie, J. Wroclawski, and E. Felstaine, Nichols, R. Braden, B. Davie, J. Wroclawski, and E. Felstaine, "A
"Integrated Services Operation over Diffserv Networks", Internet Framework for Integrated Services Operation over Diffserv
Draft <http://www.ietf.org/internet-drafts/draft-ietf-issll- Networks", RFC 2998, November 2000.
diffserv-rsvp-04.txt>, March 2000.
[EF-PHB] [EF-PHB]
V. Jacobson, K. Nichols, and K. Poduri, "An Expedited Forwarding V. Jacobson, K. Nichols, and K. Poduri, "An Expedited Forwarding
PHB", RFC 2598, June 1999. PHB", RFC 2598, June 1999.
[FLOYD] [FJ95]
S. Floyd, "General Load Sharing", 1993. S. Floyd and V. Jacobson, "Link Sharing and Resource Management
Models for Packet Networks", IEEE/ACM Transactions on Networking,
[GTC] Vol. 3 No. 4, August 1995
L. Lin, J. Lo, and F. Ou, "A Generic Traffic Conditioner", Internet
Draft <http://www.ietf.org/internet-drafts/draft-lin-diffserv-
gtc-01.txt>, August 1999.
[INTSERV] [INTSERV]
R. Braden, D. Clark and S. Shenker, "Integrated Services in the R. Braden, D. Clark and S. Shenker, "Integrated Services in the
Internet Architecture: an Overview" RFC 1633, June 1994. Internet Architecture: an Overview", RFC 1633, June 1994.
[PDBDEF]
K. Nichols and B. Carpenter, "Definition of Differentiated Services
Per Domain Behaviors and Rules for Their Specification", Internet
Draft <http://www.ietf.org/internet-drafts/draft-heinanen-diffserv-
pdb-def-03.txt>
[POLTERM] [POLTERM]
A. Westerinen et al., "Policy Terminology", Internet Draft A. Westerinen et al., "Policy Terminology", Internet Draft
<http://www.ietf.org/internet-drafts/draft-ietf-policy- <http://www.ietf.org/internet-drafts/draft-ietf-policy-
terminology-01.txt>, November 2000.
[QOSDEVMOD] [QOSDEVMOD]
J. Strassner, A. Westerinen, B. Moore, "Information Model for J. Strassner, A. Westerinen, B. Moore, "Information Model for
Describing Network Device QoS Mechanisms", Internet Draft Describing Network Device QoS Mechanisms", Internet Draft
<http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device- <http://www.ietf.org/internet-drafts/draft-ietf-policy-qos-device-
info-model-02.txt>, November 2000
[QUEUEMGMT] [QUEUEMGMT]
B. Braden et al., "Recommendations on Queue Management and B. Braden et al., "Recommendations on Queue Management and
Congestion Avoidance in the Internet", RFC 2309, April 1998. Congestion Avoidance in the Internet", RFC 2309, April 1998.
[SRTCM] [SRTCM]
J. Heinanen, and R. Guerin, "A Single Rate Three Color Marker", RFC J. Heinanen, and R. Guerin, "A Single Rate Three Color Marker", RFC
2697, September 1999. 2697, September 1999.
[TRTCM] [TRTCM]
skipping to change at page 47, line 31 skipping to change at page 48, line 38
Common specifications - Part 3: Media Access Control (MAC) Bridges: Common specifications - Part 3: Media Access Control (MAC) Bridges:
Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992 Revision. This is a revision of ISO/IEC 10038: 1993, 802.1j-1992
and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e.", and 802.6k-1992. It incorporates P802.11c, P802.1p and P802.12e.",
ISO/IEC 15802-3: 1998. ISO/IEC 15802-3: 1998.
12. Appendix A. Discussion of Token Buckets and Leaky Buckets 12. Appendix A. Discussion of Token Buckets and Leaky Buckets
The concept used for rate-control in several architectures, including The concept used for rate-control in several architectures, including
ATM, Frame Relay, Integrated Services and Differentiated Services, ATM, Frame Relay, Integrated Services and Differentiated Services,
consists of "leaky buckets" and/or "token buckets". Both of these are, consists of "leaky buckets" and/or "token buckets". Both of these are,
by definition, theoretical relationships between some defined by definition, theoretical relationships between some defined burst
burst_size, rate and interval: size, B, a rate, R, and a time interval, t:
rate = burst_size/interval R = B/t
Thus, a token bucket or leaky bucket might specify an information rate Thus, a token bucket or leaky bucket might specify an information rate
of 1.2 Mbps with a burst size of 1500 bytes. In this case, the token of 1.2 Mbps with a burst size of 1500 bytes. In this case, the token
rate is 1,200,000 bits per second, the token burst is 12,000 bits and rate is 1,200,000 bits per second, the token burst is 12,000 bits and
the token interval is 10 milliseconds. The specification says that the token interval is 10 milliseconds. The specification says that
conforming traffic will in the worst case come in 100 bursts per second conforming traffic will, in the worst case, come in 100 bursts per
of 1500 bytes and at an average rate exceeding 1.2 Mbps. second of 1500 bytes each and at an average rate not exceeding 1.2 Mbps.
A.1 Leaky Buckets A.1 Leaky Buckets
A leaky bucket algorithm is primarily used for shaping traffic as it A leaky bucket algorithm is primarily used for shaping traffic as it
leaves an interface onto the network (handled under Queues and leaves an interface onto the network (handled under Queues and
Schedulers in this model). Traffic theoretically departs from an Schedulers in this model). Traffic theoretically departs from an
interface at a rate of one bit every so many time units (in the example, interface at a rate of one bit every so many time units (in the example,
one bit every 0.83 microseconds) but, in fact, departs in multi-bit one bit every 0.83 microseconds) but, in fact, departs in multi-bit
units (packets) at a rate approximating the theoretical, as measured units (packets) at a rate approximating the theoretical, as measured
over a longer interval. In the example, it might send one 1500 byte over a longer interval. In the example, it might send one 1500 byte
packet every 10 ms or perhaps one 500 byte packet every 3.3 ms. It is packet every 10 ms or perhaps one 500 byte packet every 3.3 ms. It is
also possible to build multi-rate leaky buckets in which traffic departs also possible to build multi-rate leaky buckets in which traffic departs
from the interface at varying rates depending on recent activity or from the interface at varying rates depending on recent activity or
inactivity. inactivity.
Implementations generally seek as constant a transmission rate as Implementations generally seek as constant a transmission rate as
achievable. In theory, a 10 Mbps shaped transmission stream from an achievable. In theory, a 10 Mbps shaped transmission stream from an
algorithmic implementation and a stream which is running at 10 Mbps algorithmic implementation and a stream which is running at 10 Mbps
because its bottleneck link has been a 10 Mbps Ethernet link should be because its bottleneck link has been a 10 Mbps Ethernet link should be
skipping to change at page 48, line 27 skipping to change at page 49, line 35
token interval to another. Traffic may also be jostled by other traffic token interval to another. Traffic may also be jostled by other traffic
competing for the same transmission resources. competing for the same transmission resources.
A.2 Token Buckets A.2 Token Buckets
A token bucket, on the other hand, measures the arrival rate of traffic A token bucket, on the other hand, measures the arrival rate of traffic
from another device. This traffic may originally have been shaped using from another device. This traffic may originally have been shaped using
a leaky bucket shaper or its equivalent. The token bucket determines a leaky bucket shaper or its equivalent. The token bucket determines
whether the traffic (still) conforms to the specification. Multi-rate whether the traffic (still) conforms to the specification. Multi-rate
token buckets (e.g. token buckets with both a peak rate and a mean rate, token buckets (e.g. token buckets with both a peak rate and a mean rate,
and sometimes more) are commonly used, such as described in [SRTCM] and and sometimes more) are commonly used, such as those described in
[TRTCM]. In this case, absolute smoothness is not expected, but [SRTCM] and [TRTCM]. In this case, absolute smoothness is not expected,
conformance to one or more of the specified rates is. but conformance to one or more of the specified rates is.
Simplistically, a data stream is said to conform to a simple token Simplistically, a data stream is said to conform to a simple token
bucket parameterised by a {rate, burst_size} if the system receives in bucket parameterised by a {R, B} if the system receives in any time
any time interval, t, at most, an amount of data not exceeding (rate * interval, t, at most, an amount of data not exceeding (R * t) + B.
t) + burst_size.
For the multi-rate token bucket case, the data stream is said to conform For a multi-rate token bucket case, the data stream is said to conform
if, for each of the rates, the stream conforms to the token-bucket if, for each of the rates, the stream conforms to the token-bucket
profile appropriate for traffic of that class. For example, received profile appropriate for traffic of that class. For example, received
traffic that arrives pre-classified as one of the "excess" rates (e.g. traffic that arrives pre-classified as one of the "excess" rates (e.g.
AF12 or AF13 traffic for a device implementing the AF1x PHB) is only AF12 or AF13 traffic for a device implementing the AF1x PHB) is only
compared to the relevant "excess" token bucket profile. compared to the relevant "excess" token bucket profile.
A.3 Some consequences A.3 Some Consequences
The fact that Internet Protocol data is organized into variable length
packets introduces some uncertainty in the conformance decision made by
any downstream Meter that is attempting to determine conformance to a
traffic profile that is theoretically designed for fixed-length units of
data.
When used as a leaky bucket shaper, the above definition interacts with When used as a leaky bucket shaper, the above definition interacts with
clock granularity in ways one might not expect. A leaky bucket releases clock granularity in ways one might not expect. A leaky bucket releases
a packet only when all of its bits would have been allowed: it does not a packet only when all of its bits would have been allowed: it does not
borrow from future capacity. If the clock is very fine grain, on the borrow from future capacity. If the clock is very fine grain, on the
order of the bit rate or faster, this is not an issue. But if the clock order of the bit rate or faster, this is not an issue. But if the clock
is relatively slow (and millisecond or multi-millisecond clocks are not is relatively slow (and millisecond or multi-millisecond clocks are not
unusual in networking equipment), this can introduce jitter to the unusual in networking equipment), this can introduce jitter to the
shaped stream. shaped stream.
The fact that data is organized into variable length packets introduces This leaves an implementor of a token bucket Meter with a dilemma. When
some uncertainty in the conformance decision made by a downstream Meter the number of bandwidth tokens, b, left in the token bucket is positive
that is attempting to determine conformance to a traffic profile. but less than the size of the packet being operated on, L, one of three
Theoretically, in this case, a token bucket accepts a packet only if all actions can be performed:
of its bits would have been accepted and does not borrow the required
excess capacity from future capacity - this is referred to as a "strict"
token bucket. This is consistent with [SRTCM] and [TRTCM]. In real-
world deployment, however, where MTUs are often larger than the burst
size offered by a link-layer network service provider and TCP is more
commonly ACK-paced than shaped using a leaky bucket, a "loose" or
"lenient" token bucket definition that would accept a packet if any of
its bits were within a profile offers a solution to the practical
problems that may arise from use of a strict meter.
Internet Protocol (IP) packets are of variable-length but theoretical
token buckets operate using fixed-length time intervals or pieces of
data. This leaves an implementor of a token bucket scheme with a
dilemma. When the amount of bandwidth tokens, TB, left in the token
bucket is positive but less than the size of the packet being operated
on, one of three things can be done:
(1) The whole size of the packet can be substracted from the bucket, (1) The whole size of the packet can be substracted from the bucket,
leaving it negative, remembering that the token bucket size must leaving it negative, remembering that, when new tokens are next
be added to TB rather than simply setting it "full". This added to the bucket, the new token allocation, B, must be added
potentially puts more than the token bucket size into this token to b rather than simply setting the bucket to "full". This option
bucket interval and less into the next. It does, however, make potentially puts more than the desired burst size of data into
the average amount accepted per token bucket interval equal to this token bucket interval and correspondingly less into the
the token burst. This approach accepts traffic if any bit in the next. It does, however, keep the average amount accepted per
packet would be accepted and borrows up to one MTU of capacity token bucket interval equal to the token burst. This approach
from one or more subsequent intervals when necessary. Such a accepts traffic if any one bit in the packet would have been
token bucket implementation is said to be a "loose" token bucket. accepted and borrows up to one MTU of capacity from one or more
subsequent intervals when necessary. Such a token bucket meter
implementation is said to offer "loose" conformance to the token
bucket.
(2) Alternatively, the amount can be left unchanged (and maybe an (2) Alternatively, the packet can be rejected and the amount of
attempt could be made to accept the packet under another tokens in the bucket left unchanged (and maybe an attempt could
threshold in another bucket), remembering that the token bucket be made to accept the packet under another threshold in another
size must be added to the TB variable rather than simply setting bucket), remembering that, when new tokens are next added to the
it "full". This potentially puts less than the token bucket size bucket, the new token allocation, B, must be added to b rather
into this token bucket interval and more into the next. Like the than simply setting the bucket to "full". This potentially puts
first option, it makes the average amount accepted per token less than the permissible burst size of data into this token
bucket interval and correspondingly more into the next. Like the
first option, it keeps the average amount accepted per token
bucket interval equal to the token burst. This approach accepts bucket interval equal to the token burst. This approach accepts
traffic if every bit in the packet would be accepted and borrows traffic only if every bit in the packet would have been accepted
up to one MTU of capacity from one or more previous intervals and borrows up to one MTU of capacity from one or more previous
when necessary. Such a token bucket implementation is said to be intervals when necessary. Such a token bucket meter
a "strict" (or perhaps "stricter") token bucket. implementation is said to offer "strict" (or perhaps "stricter")
conformance to the token bucket. This option is consistent with
[SRTCM] and [TRTCM] and is often used in ATM and frame-relay
implementations.
(3) The TB variable can be set to zero to account for the first part (3) The TB variable can be set to zero to account for the first part
of the packet and the remainder of the packet size can be taken of the packet and the remainder of the packet size can be taken
out of the next-colored bucket. This, of course, has another bug: out of the next-colored bucket. This, of course, has another bug:
the same packet cannot have both conforming and nonconforming the same packet cannot have both conforming and nonconforming
components in the Diffserv architecture and so is not really components in the Diffserv architecture and so is not really
appropriate here. appropriate here and we do not discuss this option further here.
Unfortunately, the thing that cannot be done is exactly to fit the token Unfortunately, the thing that cannot be done is exactly to fit the token
burst specification with random sized packets: therefore token buckets burst specification with random sized packets: therefore token buckets
in a variable length packet environment always have a some variance from in a variable length packet environment always have a some variance from
theoretical reality. This has also been observed in the ATM Guaranteed theoretical reality. This has also been observed in the ATM Guaranteed
Frame Rate (GFR) service category specification and Frame Relay. Frame Rate (GFR) service category specification and Frame Relay. A
number of observations may be made:
Some find the behavior of a "loose" token bucket unacceptable, as it is o Operationally, a token bucket meter is reasonable for traffic which
significantly different than the token bucket description for ATM and has been shaped by a leaky bucket shaper or a serial line. However,
for Frame Relay. However, the "strict" token bucket approach has three traffic in the Internet is rarely shaped in that way: TCP applies
characteristics which are important to keep in mind: no shaping to its traffic, but rather depends on longer-range ACK-
clocking behavior to help it approximate a certain rate and
explicitly sends traffic bursts during slow start, retransmission
and fast recovery. Video-on-IP implementations such as [VIC] may
have a leaky bucket shaper available to them, but often do not, and
simply enqueue the output of their codec for transmission on the
appropriate interface. As a result, in each of these cases, a token
bucket meter may reject traffic in the short term (over a single
token interval) which it would have accepted if it had a longer
time in view and which it needs to accept for the application to
work properly. To work around this, the token interval, B/R, must
approximate or exceed the RTT of the session(s) in question and the
burst size, B, must accommodate the largest burst that the
originator might send.
(1) First, if the maximum token burst is smaller than the MTU, it is o The behavior of a loose token bucket is significantly different
possible that traffic never matches the specification. This may from the token bucket description for ATM and for Frame Relay.
be avoided by not allowing such a specification.
(2) Second, the strict token bucket specifications [SRTCM] and o A loose token bucket does not accept packets while the token count
[TRTCM], as specified, are subject to a persistent under-run. is negative. This means that, when a large packet has just borrowed
These accumulate burst capacity over time, up to the maximum tokens from the future, even a small incoming packet e.g. a 40-byte
burst size. Suppose that the maximum burst size is exactly the TCP ACK/SYN will not be accepted. Therefore, if such a loose token
size of the packets being sent - which one might call the bucket is configured with a burst size close to the MTU, some
"strictest" token bucket implementation. In such a case, when one discrimination against smaller packets can take place: use of a
packet has been accepted, the token depth becomes zero, and larger burst size avoids this problem.
starts to accumulate. If the next packet is received any time
earlier than a token interval later, it will not be accepted. If
the next packet arrives exactly on time, it will be accepted and
the token depth again set to zero. If it arrives later, however,
the token depth will stop accumulating, as it is capped by the
maximum burst size, and tokens that would have accumulated
between the end of that token interval and the actual arrival of
the packet are lost. As a result, natural jitter in the network
conspires against the algorithm to reduce the actual acceptance
rate. Overcoming this error requires the maximum token bucket
size to be significantly greater than the MTU.
(3) Third, operationally, a strict token bucket is reasonable for o The converse of the above is that a strict token bucket sometimes
traffic which has been shaped by a leaky bucket shaper or a does not accept large packets when a loose one would do so.
serial line. However, traffic in the Internet is rarely shaped in Therefore, if such a strict token bucket is configured with a burst
that way. TCP applies no shaping to its traffic, but rather size close to the MTU, some discrimination against larger packets
depends on longer-range ACK-clocking behavior to help it can take place: use of a larger burst size avoids this problem.
approximate a certain rate and explicitly sends traffic bursts
during slow start, retransmission and fast recovery. Video-on-IP
implementations such as [VIC] may have a leaky bucket shaper
available to them, but often do not, and simply enqueue the
output of their codec for transmission on the appropriate
interface. As a result, in each of these cases, a strict shaper
may reject traffic in the short term (single token interval)
which it would have accepted if it had a longer time in view and
which it needs to accept for the application to work properly. To
work around this, the token interval must approximate or exceed
the RTT of the session or sessions in question and the burst size
must accommodate the largest burst that the originator might
send.
A.4 Mathematics o In real-world deployments, MTUs are often larger than the burst
size offered by a link-layer network service provider. If so then
it is possible that a strict token bucket meter would find that
traffic never matches the specified profile: this may be avoided by
not allowing such a specification to be used. This situation cannot
arise with a loose token bucket since the smallest burst size that
can be configured is 1 bit, by definition limiting a loose token
bucket to having a burst size of greater than one MTU.
The behavior defined in [SRTCM] and [TRTCM] is not mandatory for o Both strict token bucket specifications, as specified in [SRTCM]
compliance, but we give here a mathematical definition of two- parameter and [TRTCM], and loose ones, are subject to a persistent under-run.
These accumulate burst capacity over time, up to the maximum burst
size. Suppose that the maximum burst size is exactly the size of
the packets being sent - which one might call the "strictest" token
bucket implementation. In such a case, when one packet has been
accepted, the token depth becomes zero and starts to accumulate
again. If the next packet is received any time earlier than a
token interval later, it will not be accepted. If the next packet
arrives exactly on time, it will be accepted and the token depth
again set to zero. If it arrives later, however, accumulation of
tokens will have stopped because it is capped by the maximum burst
size: during the interval between the bucket becoming full and the
actual arrival of the packet, no new tokens are added. As a result,
jitter that accumulates across multiple hops in the network
conspires against the algorithm to reduce the actual acceptance
rate. Thus it usually makes sense to set the maximum token bucket
size somewhat greater than the MTU in order to absorb some of the
jitter and allow a practical acceptance rate more in line with the
desired theoretical rate.
A.4 Mathematical Definition of Strict Token Bucket Conformance
The strict token bucket conformance behavior defined in [SRTCM] and
[TRTCM] is not mandatory for compliance with any current Diffserv
standards, but we give here a mathematical definition of two-parameter
token bucket operation which is consistent with those documents and token bucket operation which is consistent with those documents and
which can be used to define a shaping profile. which can also be used to define a shaping profile.
Define a token bucket with bucket size BS, token accumulation rate R and Define a token bucket with bucket size B, token accumulation rate R and
instantaneous token occupancy T(t). Assume that T(0) = BS. instantaneous token occupancy b(t). Assume that b(0) = B. Then after an
arbitrary interval with no packet arrivals, b(t) will not change since
Then after an arbitrary interval with no packet arrivals, T(t) will not the bucket is already full of tokens.
change since the bucket is already full of tokens. Assume a packet of
size B bytes at time t'. The bucket capacity T(t'-) = BS still. Then, as
long as B <= BS, the packet conforms to the meter, and
T(t') = BS - B. Assume a packet of size L bytes arrives at time t'. The bucket occupancy
is still B. Then, as long as L <= B, the packet conforms to the meter,
and afterwards
Assume an interval v = t - t' elapses before the next packet, of size C b(t') = B - L.
<= BS, arrives. T(t-) is given by the following equation:
T(t-) = min { BS, T(t') + v*R } Assume now an interval delta_t = t - t' elapses before the next packet
arrives, of size L' <= B. Just before this, at time t-, the bucket has
accumulated delta_t*R tokens over the interval, up to a maximum of B
tokens so that:
maximum of BS tokens). b(t-) = min{ B, b(t') + delta_t*R }
If T(t-) - C = 0, the packet conforms and T(t) = T(t-) - C. Otherwise, For a strict token bucket, the conformance test is as follows:
the packet does not conform and T(t) = T(t-).
This function can be used to define a shaping profile. If a packet of if (b(t-) - L' >= 0) {
size C arrives at time t, it will be eligible for transmission at time /* the packet conforms */
te given as follows (we still assume C <= BS): b(t) = b(t-) - L';
}
else {
/* the packet does not conform */
b(t) = b(t-);
}
This function can also be used to define a shaping profile. If a packet
of size L arrives at time t, it will be eligible for transmission at
time te given as follows (we still assume L <= B):
te = max { t, t" } te = max { t, t" }
where t" = (C - T(t') + t'*R)/R, T(t") = C, the time when C credits have where t" = (L - b(t') + t'*R) / R and b(t") = L, the time when L credits
accumulated in the bucket, and when the packet would conform if the have accumulated in the bucket, and when the packet would conform if the
token bucket were a meter. te != t" only if t > t". token bucket were a meter. te != t" only if t > t".
A mathematical definition along these lines for loose token bucket
conformance is left as an exercise for the reader.
13. Authors' Addresses 13. Authors' Addresses
Yoram Bernet Yoram Bernet
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone: +1 425 936 9568 Phone: +1 425 936 9568
E-mail: yoramb@microsoft.com E-mail: yoramb@microsoft.com
Steven Blake Steven Blake
Ericsson Ericsson
920 Main Campus Drive, Suite 500 920 Main Campus Drive, Suite 500
Raleigh, NC 27606 Raleigh, NC 27606
Phone: +1 919 472 9913 Phone: +1 919 472 9913
E-mail: slblake@torrentnet.com E-mail: steven.blake@ericsson.com
Daniel Grossman Daniel Grossman
Motorola Inc. Motorola Inc.
20 Cabot Blvd. 20 Cabot Blvd.
Mansfield, MA 02048 Mansfield, MA 02048
Phone: +1 508 261 5312 Phone: +1 508 261 5312
E-mail: dan@dma.isg.mot.com E-mail: dan@dma.isg.mot.com
Andrew Smith (editor) Andrew Smith (editor)
Allegro Networks Allegro Networks
skipping to change at page 53, line 4 skipping to change at page 54, line 38
Table of Contents Table of Contents
1 Introduction .................................................... 2 1 Introduction .................................................... 2
2 Glossary ........................................................ 4 2 Glossary ........................................................ 4
3 Conceptual Model ................................................ 6 3 Conceptual Model ................................................ 6
3.1 Components of a Diffserv Router ............................... 6 3.1 Components of a Diffserv Router ............................... 6
3.1.1 Datapath .................................................... 6 3.1.1 Datapath .................................................... 6
3.1.2 Configuration and Management Interface ...................... 8 3.1.2 Configuration and Management Interface ...................... 8
3.1.3 Optional QoS Agent Module ................................... 8 3.1.3 Optional QoS Agent Module ................................... 8
3.2 Diffserv Functions at Ingress and Egress ...................... 9 3.2 Diffserv Functions at Ingress and Egress ...................... 9
3.3 Shaping and Policing .......................................... 11
3.3 Shaping and Policing .......................................... 10
3.4 Hierarchical View of the Model ................................ 11 3.4 Hierarchical View of the Model ................................ 11
4 Classifiers ..................................................... 11 4 Classifiers ..................................................... 12
4.1 Definition .................................................... 11 4.1 Definition .................................................... 12
4.1.1 Filters ..................................................... 13 4.1.1 Filters ..................................................... 13
4.1.2 Overlapping Filters ......................................... 13 4.1.2 Overlapping Filters ......................................... 14
4.2 Examples ...................................................... 15 4.2 Examples ...................................................... 15
4.2.1 Behaviour Aggregate (BA) Classifier ......................... 15 4.2.1 Behaviour Aggregate (BA) Classifier ......................... 15
4.2.2 Multi-Field (MF) Classifier ................................. 15 4.2.2 Multi-Field (MF) Classifier ................................. 15
4.2.3 Free-form Classifier ........................................ 16 4.2.3 Free-form Classifier ........................................ 16
4.2.4 Other Possible Classifiers .................................. 16 4.2.4 Other Possible Classifiers .................................. 16
5 Meters .......................................................... 17 5 Meters .......................................................... 17
5.1 Examples ...................................................... 18 5.1 Examples ...................................................... 18
5.1.1 Average Rate Meter .......................................... 18 5.1.1 Average Rate Meter .......................................... 18
5.1.2 Exponential Weighted Moving Average (EWMA) Meter ............ 19 5.1.2 Exponential Weighted Moving Average (EWMA) Meter ............ 19
5.1.3 Two-Parameter Token Bucket Meter ............................ 19 5.1.3 Two-Parameter Token Bucket Meter ............................ 19
5.1.4 Multi-Stage Token Bucket Meter .............................. 20 5.1.4 Multi-Stage Token Bucket Meter .............................. 20
5.1.5 Null Meter .................................................. 21 5.1.5 Null Meter .................................................. 21
6 Action Elements ................................................. 21 6 Action Elements ................................................. 21
6.1 DSCP Marker ................................................... 22 6.1 DSCP Marker ................................................... 22
6.2 Absolute Dropper .............................................. 22 6.2 Absolute Dropper .............................................. 22
6.3 Multiplexor ................................................... 22 6.3 Multiplexor ................................................... 23
6.4 Counter ....................................................... 23 6.4 Counter ....................................................... 23
6.5 Null Action ................................................... 23 6.5 Null Action ................................................... 23
7 Queueing Elements ............................................... 23 7 Queueing Elements ............................................... 23
7.1 Queueing Model ................................................ 24 7.1 Queueing Model ................................................ 24
7.1.1 FIFO Queue .................................................. 24 7.1.1 FIFO Queue .................................................. 25
7.1.2 Scheduler ................................................... 25 7.1.2 Scheduler ................................................... 26
7.1.3 Algorithmic Dropper ......................................... 27 7.1.3 Algorithmic Dropper ......................................... 28
7.2 Sharing load among traffic streams using queueing ............. 31 7.2 Sharing load among traffic streams using queueing ............. 31
7.2.1 Load Sharing ................................................ 31 7.2.1 Load Sharing ................................................ 32
7.2.2 Traffic Priority ............................................ 32 7.2.2 Traffic Priority ............................................ 33
8 Traffic Conditioning Blocks (TCBs) .............................. 32 8 Traffic Conditioning Blocks (TCBs) .............................. 33
8.1 TCB ........................................................... 33 8.1 TCB ........................................................... 34
8.1.1 Building blocks for Queueing ................................ 34 8.1.1 Building blocks for Queueing ................................ 35
8.2 An Example TCB ................................................ 34 8.2 An Example TCB ................................................ 35
8.3 An Example TCB to Support Multiple Customers .................. 39 8.3 An Example TCB to Support Multiple Customers .................. 40
8.4 TCBs Supporting Microflow-based Services ...................... 41 8.4 TCBs Supporting Microflow-based Services ...................... 42
8.5 Cascaded TCBs ................................................. 44 8.5 Cascaded TCBs ................................................. 45
9 Security Considerations ......................................... 45 9 Security Considerations ......................................... 46
10 Acknowledgments ................................................ 45 10 Acknowledgments ................................................ 46
11 References ..................................................... 45 11 References ..................................................... 46
12 Appendix A. Discussion of Token Buckets and Leaky Buckets ...... 47 12 Appendix A. Discussion of Token Buckets and Leaky Buckets ...... 48
13 Authors' Addresses ............................................. 52 13 Authors' Addresses ............................................. 53
14. Full Copyright 14. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 111 change blocks. 
383 lines changed or deleted 470 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/