rfc2597.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   thus coexist with the AF PHB group and retain the forwarding behavior
   and relationships that was defined for them.  In particular, the
   Default PHB codepoint of '000000' may remain to be used for
   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 conditioning
   actions that limit the amount of traffic in each AF class to a
   (generally different) percentage of the class's allocated resources,
   can be used to obtain the overall behavior implied by the Class
   Selector PHBs.  In this case it may be appropriate within a DS domain
   to use some or all of the Class Selector codepoints as aliases of AF
   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, any
   AF PHB group implementation should document the following:

   (a) Which, if any, other PHB groups may preempt the forwarding
   resources specifically allocated to each AF PHB class.  This
   preemption MUST NOT happen in normal network operation, but may be
   appropriate in certain unusual situations - for example, the '11x000'
   codepoint may preempt AF forwarding resources, to give precedence to
   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 and
   other implemented PHB groups.  For example, once the minimum
   allocations are given to each AF class, any remaining resources could
   be allocated evenly between the AF classes and the Default PHB.  In
   an alternative example, any remaining resources could be allocated to
   forwarding excess AF traffic, with resources devoted to the Default
   PHB only when all AF demand is met.

   This memo does not specify that any particular relationship hold
   between AF PHB groups and other implemented PHB groups; it requires
   only that whatever relationship is chosen be documented.
   Implementations MAY allow either or both of these relationships to be
   configurable.  It is expected that this level of configuration
   flexibility will prove valuable to many network administrators.

8. Security Implications

   In order to protect itself against denial of service attacks, a
   provider DS domain SHOULD limit the traffic entering the domain to
   the subscribed profiles.  Also, in order to protect a link to a
   customer DS domain from denial of service attacks, the provider DS
   domain SHOULD allow the customer DS domain to specify how the
   resources of the link are allocated to AF packets.  If a service
   offering requires that traffic marked with an AF codepoint be limited
   by such attributes as source or destination address, it is the
   responsibility of the ingress node in a network to verify validity of
   such attributes.

   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].










Heinanen                    Standards Track                     [Page 7]

RFC 2597              Assured Forwarding PHB Group             June 1999


Appendix: Example Services

   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 three
   classes so that packets in the gold class experience lighter load
   (and thus have greater probability for timely forwarding) than
   packets assigned to the silver class.  Same kind of relationship
   exists between the silver class and the bronze class.  If desired,
   packets within each class may be further separated by giving them
   either low, medium, or high drop precedence.

   The bronze, silver, and gold service classes could in the network be
   mapped to the AF classes 1, 2, and 3.  Similarly, low, medium, and
   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 parameters
   a rate and a size, which is the sum of two burst values: a committed
   burst size and an excess burst size.  A packet is assigned low drop
   precedence if the number of tokens in the bucket is greater than the
   excess burst size, medium drop precedence if the number of tokens in
   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 be
   necessary to set an upper limit to the amount of high drop precedence
   traffic from a customer DS domain in order to avoid the situation
   where an avalanche of undeliverable high drop precedence packets from
   one customer DS domain can deny service to possibly deliverable high
   drop precedence packets from other domains.

   Another way to assign the drop precedence level of a packet could be
   to limit the user traffic of an Olympic service class to a given peak
   rate and distribute it evenly across each level of drop precedence.
   This would yield a proportional bandwidth service, which equally
   apportions available capacity during times of congestion under the
   assumption that customers with high bandwidth microflows have
   subscribed to higher peak rates than customers with low bandwidth
   microflows.

   The AF PHB group could also be used to implement a loss and low
   latency service using an over provisioned AF class, if the maximum
   arrival rate to that class is known a priori in each DS node.
   Specification of the required admission control services, however, is
   beyond the scope of this document.  If low loss is not an objective,
   a low latency service could be implemented without over provisioning
   by setting a low maximum limit to the buffer space available for an
   AF class.



Heinanen                    Standards Track                     [Page 8]

RFC 2597              Assured Forwarding PHB Group             June 1999


References

   [Blake]   Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and
             W. Weiss, "An Architecture for Differentiated Services",
             RFC 2475, December 1998.

   [Bradner] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [Clark]   Clark, D. and Fang, W., Explicit Allocation of Best Effort
             Packet Delivery Service.  IEEE/ACM Transactions on
             Networking, Volume 6, Number 4, August 1998, pp. 362-373.

   [Floyd]   Floyd, S., and Jacobson, V., Random Early Detection
             gateways for Congestion Avoidance. IEEE/ACM Transactions on
             Networking, Volume 1, Number 4, August 1993, pp. 397-413.

   [Nichols] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition
             of the Differentiated Services Field (DS Field) in the IPv4
             and IPv6 Headers", RFC 2474, December 1998.































Heinanen                    Standards Track                     [Page 9]

RFC 2597              Assured Forwarding PHB Group             June 1999


Authors' Addresses

   Juha Heinanen
   Telia Finland
   Myyrmaentie 2
   01600 Vantaa, Finland

   EMail: [e-mail]


   Fred Baker
   Cisco Systems
   519 Lado Drive
   Santa Barbara, California 93111

   EMail: [e-mail]


   Walter Weiss
   Lucent Technologies
   300 Baker Avenue, Suite 100,
   Concord, MA  01742-2168

   EMail: [e-mail]


   John Wroclawski
   MIT Laboratory for Computer Science
   545 Technology Sq.
   Cambridge, MA  02139

   EMail: [e-mail]



















Heinanen                    Standards Track                    [Page 10]

RFC 2597              Assured Forwarding PHB Group             June 1999


Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Heinanen                    Standards Track                    [Page 11]