As per Relevance of the word congestion, we have this rfc below:
Network Working Group J.
Request for Comments: 2597 Telia
Category: Standards Track F.
Cisco
W.
Lucent
J.
MIT
June 1999
Assured Forwarding PHB
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document defines a general use Differentiated Services (DS
[Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF).
The AF PHB group provides delivery of IP packets in
independently forwarded AF classes. Within each AF class, an
packet can be assigned one of three different levels of
precedence. A DS node does not reorder IP packets of the
microflow if they belong to the same AF class
1. Purpose and
There is a demand to provide assured forwarding of IP packets
the Internet. In a typical application, a company uses the
to interconnect its geographically distributed sites and wants
assurance that IP packets within this intranet are forwarded
high probability as long as the aggregate traffic from each site
not exceed the subscribed information rate (profile). It
desirable that a site may exceed the subscribed profile with
understanding that the excess traffic is not delivered with as
probability as the traffic that is within the profile. It is
Heinanen Standards Track [Page 1]
RFC 2597 Assured Forwarding PHB Group June 1999
important that the network does not reorder packets that belong
the same microflow, as defined in [Nichols], no matter if they are
or out of the profile
Assured Forwarding (AF) PHB group is a means for a provider DS
to offer different levels of forwarding assurances for IP
received from a customer DS domain. Four AF classes are defined
where each AF class is in each DS node allocated a certain amount
forwarding resources (buffer space and bandwidth). IP packets
wish to use the services provided by the AF PHB group are assigned
the customer or the provider DS domain into one or more of these
classes according to the services that the customer has
to. Further background about this capability and some ways to use
may be found in [Clark].
Within each AF class IP packets are marked (again by the customer
the provider DS domain) with one of three possible drop
values. In case of congestion, the drop precedence of a
determines the relative importance of the packet within the AF class
A congested DS node tries to protect packets with a lower
precedence value from being lost by preferably discarding
with a higher drop precedence value
In a DS node, the level of forwarding assurance of an IP packet
depends on (1) how much forwarding resources has been allocated
the AF class that the packet belongs to, (2) what is the current
of the AF class, and, in case of congestion within the class, (3)
what is the drop precedence of the packet
For example, if traffic conditioning actions at the ingress of
provider DS domain make sure that an AF class in the DS nodes is
moderately loaded by packets with the lowest drop precedence
and is not overloaded by packets with the two lowest drop
values, then the AF class can offer a high level of
assurance for packets that are within the subscribed profile (i.e.,
marked with the lowest drop precedence value) and offer up to
lower levels of forwarding assurance for the excess traffic
This document describes the AF PHB group. An otherwise DS-
node is not required to implement this PHB group in order to
considered DS-compliant, but when a DS-compliant node is said
implement an AF PHB group, it must conform to the specification
this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [Bradner].
Heinanen Standards Track [Page 2]
RFC 2597 Assured Forwarding PHB Group June 1999
2. The AF PHB
Assured Forwarding (AF) PHB group provides forwarding of IP
in N independent AF classes. Within each AF class, an IP packet
assigned one of M different levels of drop precedence. An IP
that belongs to an AF class i and has drop precedence j is
with the AF codepoint AFij, where 1 <= i <= N and 1 <= j <= M
Currently, four classes (N=4) with three levels of drop precedence
each class (M=3) are defined for general use. More AF classes
levels of drop precedence MAY be defined for local use
A DS node SHOULD implement all four general use AF classes.
in one AF class MUST be forwarded independently from packets
another AF class, i.e., a DS node MUST NOT aggregate two or more
classes together
A DS node MUST allocate a configurable, minimum amount of
resources (buffer space and bandwidth) to each implemented AF class
Each class SHOULD be serviced in a manner to achieve the
service rate (bandwidth) over both small and large time scales
An AF class MAY also be configurable to receive more
resources than the minimum when excess resources are available
from other AF classes or from other PHB groups. This memo does
specify how the excess resources should be allocated,
implementations MUST specify what algorithms are actually
and how they can be parameterized
Within an AF class, a DS node MUST NOT forward an IP packet
smaller probability if it contains a drop precedence value p than
it contains a drop precedence value q when p < q. Note that
requirement can be fulfilled without needing to dequeue and
already-queued packets
Within each AF class, a DS node MUST accept all three drop
codepoints and they MUST yield at least two different levels of
probability. In some networks, particularly in enterprise networks
where transient congestion is a rare and brief occurrence, it may
reasonable for a DS node to implement only two different levels
loss probability per AF class. While this may suffice for
networks, three different levels of loss probability SHOULD
supported in DS domains where congestion is a common occurrence
If a DS node only implements two different levels of loss
for an AF class x, the codepoint AFx1 MUST yield the lower
probability and the codepoints AFx2 and AFx3 MUST yield the
loss probability
Heinanen Standards Track [Page 3]
RFC 2597 Assured Forwarding PHB Group June 1999
A DS node MUST NOT reorder AF packets of the same microflow when
belong to the same AF class regardless of their drop precedence
There are no quantifiable timing requirements (delay or
variation) associated with the forwarding of AF packets
The relationship between AF classes and other PHBs is described
Section 7 of this memo
The AF PHB group MAY be used to implement both end-to-end and
edge-to-domain edge services
3. Traffic Conditioning
A DS domain MAY at the edge of a domain control the amount of
traffic that enters or exits the domain at various levels of
precedence. Such traffic conditioning actions MAY include
shaping, discarding of packets, increasing or decreasing the
precedence of packets, and reassigning of packets to other
classes. However, the traffic conditioning actions MUST NOT
reordering of packets of the same microflow
4. Queueing and Discard
This section defines the queueing and discard behavior of the AF
group. Other aspects of the PHB group's behavior are defined
Section 2.
An AF implementation MUST attempt to minimize long-term
within each class, while allowing short-term congestion
from bursts. This requires an active queue management algorithm.
example of such an algorithm is Random Early Drop (RED) [Floyd].
This memo does not specify the use of a particular algorithm,
does require that several properties hold
An AF implementation MUST detect and respond to long-term
within each class by dropping packets, while handling short-
congestion (packet bursts) by queueing packets. This implies
presence of a smoothing or filtering function that monitors
instantaneous congestion level and computes a smoothed
level. The dropping algorithm uses this smoothed congestion level
determine when packets should be discarded
The dropping algorithm MUST be insensitive to the short-term
characteristics of the microflows using an AF class. That is,
with different short-term burst shapes but identical longer-
packet rates should have packets discarded with essentially
probability. One way to achieve this is to use randomness within
dropping function
Heinanen Standards Track [Page 4]
RFC 2597 Assured Forwarding PHB Group June 1999
The dropping algorithm MUST treat all packets within a single
and precedence level identically. This implies that for any
smoothed congestion level, the discard rate of a
microflow's packets within a single precedence level will
proportional to that flow's percentage of the total amount of
passing through that precedence level
The congestion indication feedback to the end nodes, and thus
level of packet discard at each drop precedence in relation
congestion, MUST be gradual rather than abrupt, to allow the
system to reach a stable operating point. One way to do this (RED
uses two (configurable) smoothed congestion level thresholds.
the smoothed congestion level is below the first threshold,
packets of the relevant precedence are discarded. When the
congestion level is between the first and the second threshold
packets are discarded with linearly increasing probability,
from zero to a configurable value reached just prior to the
threshold. When the smoothed congestion level is above the
threshold, packets of the relevant precedence are discarded with 100%
probability
To allow the AF PHB to be used in many different
environments, the dropping algorithm control parameters MUST
independently configurable for each packet drop precedence and
each AF class
Within the limits above, this specification allows for a range
packet discard behaviors. Inconsistent discard behaviors lead
inconsistent end-to-end service semantics and limit the range
possible uses of the AF PHB in a multi-vendor environment.
experience is gained, future versions of this document may
tightly define specific aspects of the desirable behavior
5.
When AF packets are tunneled, the PHB of the tunneling packet
NOT reduce the forwarding assurance of the tunneled AF packet
cause reordering of AF packets belonging to the same microflow
Heinanen Standards Track [Page 5]
RFC 2597 Assured Forwarding PHB Group June 1999
6. Recommended
Recommended codepoints for the four general use AF classes are
below. These codepoints do not overlap with any other general use
groups
The RECOMMENDED values of the AF codepoints are as follows: AF11 = '
001010', AF12 = '001100', AF13 = '001110', AF21 = '010010', AF22 = '
010100', AF23 = '010110', AF31 = '011010', AF32 = '011100', AF33 = '
011110', AF41 = '100010', AF42 = '100100', and AF43 = '100110'.
table below summarizes the recommended AF codepoint values
Class 1 Class 2 Class 3 Class 4
+----------+----------+----------+----------+
Low Drop Prec | 001010 | 010010 | 011010 | 100010 |
Medium Drop Prec | 001100 | 010100 | 011100 | 100100 |
High Drop Prec | 001110 | 010110 | 011110 | 100110 |
+----------+----------+----------+----------+
7. Interactions with Other PHB
The AF codepoint mappings recommended above do not interfere with
local use spaces nor the Class Selector codepoints recommended
[Nichols]. The PHBs selected by those Class Selector codepoints
thus coexist with the AF PHB group and retain the forwarding
and relationships that was defined for them. In particular,
Default PHB codepoint of '000000' may remain to be used
conventional best effort traffic. Similarly, the codepoints '11x000'
may remain to be used for network control traffic
The AF PHB group, in conjunction with edge traffic
actions that limit the amount of traffic in each AF class to
(generally different) percentage of the class's allocated resources
can be used to obtain the overall behavior implied by the
Selector PHBs. In this case it may be appropriate within a DS
to use some or all of the Class Selector codepoints as aliases of
codepoints
In addition to the Class Selector PHBs, any other PHB groups may co
exist with the AF PHB group within the same DS domain. However,
AF PHB group implementation should document the following
(a) Which, if any, other PHB groups may preempt the
resources specifically allocated to each AF PHB class.
preemption MUST NOT happen in normal network operation, but may
appropriate in certain unusual situations - for example, the '11x000'
codepoint may preempt AF forwarding resources, to give precedence
unexpectedly high levels of network control traffic when required
Heinanen Standards Track [Page 6]
RFC 2597 Assured Forwarding PHB Group June 1999
(b) How "excess" resources are allocated between the AF PHB group
other implemented PHB groups. For example, once the
allocations are given to each AF class, any remaining resources
be allocated evenly between the AF classes and the Default PHB.
an alternative example, any remaining resources could be allocated
forwarding excess AF traffic, with resources devoted to the
PHB only when all AF demand is met
This memo does not specify that any particular relationship
between AF PHB groups and other implemented PHB groups; it
only that whatever relationship is chosen be documented
Implementations MAY allow either or both of these relationships to
configurable. It is expected that this level of
flexibility will prove valuable to many network administrators
8. Security
In order to protect itself against denial of service attacks,
provider DS domain SHOULD limit the traffic entering the domain
the subscribed profiles. Also, in order to protect a link to
customer DS domain from denial of service attacks, the provider
domain SHOULD allow the customer DS domain to specify how
resources of the link are allocated to AF packets. If a
offering requires that traffic marked with an AF codepoint be
by such attributes as source or destination address, it is
responsibility of the ingress node in a network to verify validity
such attributes
Other security considerations are covered in [Blake] and [Nichols].
9. Intellectual Property
The IETF has been notified of intellectual property rights claimed
regard to some or all of the specification contained in
document. For more information, consult the online list of
rights
10. IANA
This document allocates twelve codepoints, listed in section 6,
Pool 1 of the code space defined by [Nichols].
Heinanen Standards Track [Page 7]
RFC 2597 Assured Forwarding PHB Group June 1999
Appendix: Example
The AF PHB group could be used to implement, for example, the so
called Olympic service, which consists of three service classes
bronze, silver, and gold. Packets are assigned to these
classes so that packets in the gold class experience lighter
(and thus have greater probability for timely forwarding)
packets assigned to the silver class. Same kind of
exists between the silver class and the bronze class. If desired
packets within each class may be further separated by giving
either low, medium, or high drop precedence
The bronze, silver, and gold service classes could in the network
mapped to the AF classes 1, 2, and 3. Similarly, low, medium,
high drop precedence may be mapped to AF drop precedence levels 1, 2,
or 3.
The drop precedence level of a packet could be assigned, for example
by using a leaky bucket traffic policer, which has as its
a rate and a size, which is the sum of two burst values: a
burst size and an excess burst size. A packet is assigned low
precedence if the number of tokens in the bucket is greater than
excess burst size, medium drop precedence if the number of tokens
the bucket is greater than zero, but at most the excess burst size
and high drop precedence if the bucket is empty. It may also
necessary to set an upper limit to the amount of high drop
traffic from a customer DS domain in order to avoid the
where an avalanche of undeliverable high drop precedence packets
one customer DS domain can deny service to possibly deliverable
drop precedence packets from other domains
Another way to assign the drop precedence level of a packet could
to limit the user traffic of an Olympic service class to a given
rate and distribute it evenly across each level of drop precedence
This would yield a proportional bandwidth service, which
apportions available capacity during times of congestion under
assumption that customers with high bandwidth microflows
subscribed to higher peak rates than customers with low
microflows
The AF PHB group could also be used to implement a loss and
latency service using an over provisioned AF class, if the
arrival rate to that class is known a priori in each DS node
Specification of the required admission control services, however,
beyond the scope of this document. If low loss is not an objective
a low latency service could be implemented without over
by setting a low maximum limit to the buffer space available for
AF class
Heinanen Standards Track [Page 8]
RFC 2597 Assured Forwarding PHB Group June 1999
[Blake] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
W. Weiss, "An Architecture for Differentiated Services",
RFC 2475, December 1998.
[Bradner] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[Clark] Clark, D. and Fang, W., Explicit Allocation of Best
Packet Delivery Service. IEEE/ACM Transactions
Networking, Volume 6, Number 4, August 1998, pp. 362-373.
[Floyd] Floyd, S., and Jacobson, V., Random Early
gateways for Congestion Avoidance. IEEE/ACM Transactions
Networking, Volume 1, Number 4, August 1993, pp. 397-413.
[Nichols] Nichols, K., Blake, S., Baker, F. and D. Black, "
of the Differentiated Services Field (DS Field) in the IPv
and IPv6 Headers", RFC 2474, December 1998.
Heinanen Standards Track [Page 9]
RFC 2597 Assured Forwarding PHB Group June 1999
Authors'
Juha
Telia
Myyrmaentie 2
01600 Vantaa,
EMail: jh@telia.
Fred
Cisco
519 Lado
Santa Barbara, California 93111
EMail: fred@cisco.
Walter
Lucent
300 Baker Avenue, Suite 100,
Concord, MA 01742-2168
EMail: wweiss@lucent.
John
MIT Laboratory for Computer
545 Technology Sq
Cambridge, MA 02139
EMail: jtw@lcs.mit.
Heinanen Standards Track [Page 10]
RFC 2597 Assured Forwarding PHB Group June 1999
Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Heinanen Standards Track [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
