draft-ietf-diffserv-af-06.txt   rfc2597.txt 
Internet Engineering Task Force Juha Heinanen Network Working Group J. Heinanen
INTERNET DRAFT Telia Finland Request for Comments: 2597 Telia Finland
Expires August 1999 Fred Baker Category: Standards Track F. Baker
Cisco Systems Cisco Systems
Walter Weiss W. Weiss
Lucent Technologies Lucent Technologies
John Wroclawski J. Wroclawski
MIT LCS MIT LCS
February, 1999 June 1999
Assured Forwarding PHB Group Assured Forwarding PHB Group
<draft-ietf-diffserv-af-06.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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.
Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
This document defines a general use Differentiated Services (DS) This document defines a general use Differentiated Services (DS)
[Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [Blake] Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF).
The AF PHB group provides delivery of IP packets in four The AF PHB group provides delivery of IP packets in four
independently forwarded AF classes. Within each AF class, an IP independently forwarded AF classes. Within each AF class, an IP
packet can be assigned one of three different levels of drop packet can be assigned one of three different levels of drop
precedence. A DS node does not reorder IP packets of the same precedence. A DS node does not reorder IP packets of the same
microflow if they belong to the same AF class. microflow if they belong to the same AF class.
skipping to change at page 2, line ? skipping to change at page 2, line 5
There is a demand to provide assured forwarding of IP packets over There is a demand to provide assured forwarding of IP packets over
the Internet. In a typical application, a company uses the Internet the Internet. In a typical application, a company uses the Internet
to interconnect its geographically distributed sites and wants an to interconnect its geographically distributed sites and wants an
assurance that IP packets within this intranet are forwarded with assurance that IP packets within this intranet are forwarded with
high probability as long as the aggregate traffic from each site does high probability as long as the aggregate traffic from each site does
not exceed the subscribed information rate (profile). It is not exceed the subscribed information rate (profile). It is
desirable that a site may exceed the subscribed profile with the desirable that a site may exceed the subscribed profile with the
understanding that the excess traffic is not delivered with as high understanding that the excess traffic is not delivered with as high
probability as the traffic that is within the profile. It is also probability as the traffic that is within the profile. It is also
important that the network does not reorder packets that belong to important that the network does not reorder packets that belong to
the same microflow no matter if they are in or out of the profile. the same microflow, as defined in [Nichols], no matter if they are in
or out of the profile.
Assured Forwarding (AF) PHB group is a means for a provider DS domain Assured Forwarding (AF) PHB group is a means for a provider DS domain
to offer different levels of forwarding assurances for IP packets to offer different levels of forwarding assurances for IP packets
received from a customer DS domain. Four AF classes are defined, received from a customer DS domain. Four AF classes are defined,
where each AF class is in each DS node allocated a certain amount of where each AF class is in each DS node allocated a certain amount of
forwarding resources (buffer space and bandwidth). IP packets that forwarding resources (buffer space and bandwidth). IP packets that
wish to use the services provided by the AF PHB group are assigned by wish to use the services provided by the AF PHB group are assigned by
the customer or the provider DS domain into one or more of these AF the customer or the provider DS domain into one or more of these AF
classes according to the services that the customer has subscribed classes according to the services that the customer has subscribed
to. Further background about this capability and some ways to use it to. Further background about this capability and some ways to use it
skipping to change at page 4, line 37 skipping to change at page 4, line 23
The AF PHB group MAY be used to implement both end-to-end and domain The AF PHB group MAY be used to implement both end-to-end and domain
edge-to-domain edge services. edge-to-domain edge services.
3. Traffic Conditioning Actions 3. Traffic Conditioning Actions
A DS domain MAY at the edge of a domain control the amount of AF A DS domain MAY at the edge of a domain control the amount of AF
traffic that enters or exits the domain at various levels of drop traffic that enters or exits the domain at various levels of drop
precedence. Such traffic conditioning actions MAY include traffic precedence. Such traffic conditioning actions MAY include traffic
shaping, discarding of packets, increasing or decreasing the drop shaping, discarding of packets, increasing or decreasing the drop
precedence of packets, and reassigning of packets to other AF precedence of packets, and reassigning of packets to other AF
classes. The traffic conditioning actions MUST NOT cause reordering classes. However, the traffic conditioning actions MUST NOT cause
of packets of the same microflow. reordering of packets of the same microflow.
4. Queueing and Discard Behavior 4. Queueing and Discard Behavior
This section defines the queueing and discard behavior of the AF PHB This section defines the queueing and discard behavior of the AF PHB
group. Other aspects of the PHB group's behavior are defined in group. Other aspects of the PHB group's behavior are defined in
Section 2. Section 2.
An AF implementation MUST attempt to minimize long-term congestion An AF implementation MUST attempt to minimize long-term congestion
within each class, while allowing short-term congestion resulting within each class, while allowing short-term congestion resulting
from bursts. This requires an active queue management algorithm. An from bursts. This requires an active queue management algorithm. An
skipping to change at page 6, line 17 skipping to change at page 6, line 11
When AF packets are tunneled, the PHB of the tunneling packet MUST When AF packets are tunneled, the PHB of the tunneling packet MUST
NOT reduce the forwarding assurance of the tunneled AF packet nor NOT reduce the forwarding assurance of the tunneled AF packet nor
cause reordering of AF packets belonging to the same microflow. cause reordering of AF packets belonging to the same microflow.
6. Recommended Codepoints 6. Recommended Codepoints
Recommended codepoints for the four general use AF classes are given Recommended codepoints for the four general use AF classes are given
below. These codepoints do not overlap with any other general use PHB below. These codepoints do not overlap with any other general use PHB
groups. groups.
The RECOMMENDED values of the AF codepoints are as follows: AF11 = The RECOMMENDED values of the AF codepoints are as follows: AF11 = '
'001010', AF12 = '001100', AF13 = '001110', AF21 = '010010', AF22 = 001010', AF12 = '001100', AF13 = '001110', AF21 = '010010', AF22 = '
'010100', AF23 = '010110', AF31 = '011010', AF32 = '011100', AF33 = 010100', AF23 = '010110', AF31 = '011010', AF32 = '011100', AF33 = '
'011110', AF41 = '100010', AF42 = '100100', and AF43 = '100110'. The 011110', AF41 = '100010', AF42 = '100100', and AF43 = '100110'. The
table below summarizes the recommended AF codepoint values. table below summarizes the recommended AF codepoint values.
Class 1 Class 2 Class 3 Class 4 Class 1 Class 2 Class 3 Class 4
+----------+----------+----------+----------+ +----------+----------+----------+----------+
Low Drop Prec | 001010 | 010010 | 011010 | 100010 | Low Drop Prec | 001010 | 010010 | 011010 | 100010 |
Medium Drop Prec | 001100 | 010100 | 011100 | 100100 | Medium Drop Prec | 001100 | 010100 | 011100 | 100100 |
High Drop Prec | 001110 | 010110 | 011110 | 100110 | High Drop Prec | 001110 | 010110 | 011110 | 100110 |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
7. Interactions with Other PHB Groups 7. Interactions with Other PHB Groups
skipping to change at page 7, line 42 skipping to change at page 7, line 35
customer DS domain from denial of service attacks, the provider DS customer DS domain from denial of service attacks, the provider DS
domain SHOULD allow the customer DS domain to specify how the domain SHOULD allow the customer DS domain to specify how the
resources of the link are allocated to AF packets. If a service resources of the link are allocated to AF packets. If a service
offering requires that traffic marked with an AF codepoint be limited offering requires that traffic marked with an AF codepoint be limited
by such attributes as source or destination address, it is the by such attributes as source or destination address, it is the
responsibility of the ingress node in a network to verify validity of responsibility of the ingress node in a network to verify validity of
such attributes. such attributes.
Other security considerations are covered in [Blake] and [Nichols]. Other security considerations are covered in [Blake] and [Nichols].
9. Intellectual Property Rights
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information, consult the online list of claimed
rights.
10. IANA Considerations
This document allocates twelve codepoints, listed in section 6, in
Pool 1 of the code space defined by [Nichols].
Appendix: Example Services Appendix: Example Services
The AF PHB group could be used to implement, for example, the so- The AF PHB group could be used to implement, for example, the so-
called Olympic service, which consists of three service classes: called Olympic service, which consists of three service classes:
bronze, silver, and gold. Packets are assigned to these three bronze, silver, and gold. Packets are assigned to these three
classes so that packets in the gold class experience lighter load classes so that packets in the gold class experience lighter load
(and thus have greater probability for timely forwarding) than (and thus have greater probability for timely forwarding) than
packets assigned to the silver class. Same kind of relationship packets assigned to the silver class. Same kind of relationship
exists between the silver class and the bronze class. If desired, exists between the silver class and the bronze class. If desired,
packets within each class may be further separated by giving them packets within each class may be further separated by giving them
skipping to change at page 8, line 44 skipping to change at page 9, line 7
latency service using an over provisioned AF class, if the maximum latency service using an over provisioned AF class, if the maximum
arrival rate to that class is known a priori in each DS node. arrival rate to that class is known a priori in each DS node.
Specification of the required admission control services, however, is Specification of the required admission control services, however, is
beyond the scope of this document. If low loss is not an objective, beyond the scope of this document. If low loss is not an objective,
a low latency service could be implemented without over provisioning a low latency service could be implemented without over provisioning
by setting a low maximum limit to the buffer space available for an by setting a low maximum limit to the buffer space available for an
AF class. AF class.
References References
[Blake] Blake, Steve, et al., An Architecture for Differentiated [Blake] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and
Services. RFC 2475, December 1998. W. Weiss, "An Architecture for Differentiated Services",
RFC 2475, December 1998.
[Bradner] Bradner, S., Key words for use in RFCs to Indicate [Bradner] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels. RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[Clark] Clark, D. and Fang, W., Explicit Allocation of Best Effort [Clark] Clark, D. and Fang, W., Explicit Allocation of Best Effort
Packet Delivery Service. IEEE/ACM Transactions on Networking, Volume Packet Delivery Service. IEEE/ACM Transactions on
6, Number 4, August 1998, pp. 362-373. Networking, Volume 6, Number 4, August 1998, pp. 362-373.
[Floyd] Floyd, S., and Jacobson, V., Random Early Detection gateways [Floyd] Floyd, S., and Jacobson, V., Random Early Detection
for Congestion Avoidance. IEEE/ACM Transactions on Networking, Volume gateways for Congestion Avoidance. IEEE/ACM Transactions on
1, Number 4, August 1993, pp. 397-413. Networking, Volume 1, Number 4, August 1993, pp. 397-413.
[Nichols] Nichols, Kathleen, et al., Definition of the Differentiated [Nichols] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition
Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474, of the Differentiated Services Field (DS Field) in the IPv4
December 1998. and IPv6 Headers", RFC 2474, December 1998.
Author Information Authors' Addresses
Juha Heinanen Juha Heinanen
Telia Finland Telia Finland
Myyrmaentie 2 Myyrmaentie 2
01600 Vantaa, Finland 01600 Vantaa, Finland
Email: jh@telia.fi
EMail: jh@telia.fi
Fred Baker Fred Baker
Cisco Systems Cisco Systems
519 Lado Drive 519 Lado Drive
Santa Barbara, California 93111 Santa Barbara, California 93111
E-mail: fred@cisco.com
EMail: fred@cisco.com
Walter Weiss Walter Weiss
Lucent Technologies Lucent Technologies
300 Baker Avenue, Suite 100, 300 Baker Avenue, Suite 100,
Concord, MA 01742-2168 Concord, MA 01742-2168
E-mail: wweiss@lucent.com
EMail: wweiss@lucent.com
John Wroclawski John Wroclawski
MIT Laboratory for Computer Science MIT Laboratory for Computer Science
545 Technology Sq. 545 Technology Sq.
Cambridge, MA 02139 Cambridge, MA 02139
Email: jtw@lcs.mit.edu
EMail: jtw@lcs.mit.edu
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved. Copyright (C) The Internet Society (1999). 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 implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, 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
skipping to change at line 447 skipping to change at page 11, line 32
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 23 change blocks. 
54 lines changed or deleted 56 lines changed or added

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