rfc2598.txt

RFC 的详细文档！

Network Working Group                                        V. Jacobson
Request for Comments: 2598                                    K. Nichols
Category: Standards Track                                  Cisco Systems
                                                               K. Poduri
                                                            Bay Networks
                                                               June 1999


                      An Expedited Forwarding PHB

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   The definition of PHBs (per-hop forwarding behaviors) is a critical
   part of the work of the Diffserv Working Group.  This document
   describes a PHB called Expedited Forwarding. We show the generality
   of this PHB by noting that it can be produced by more than one
   mechanism and give an example of its use to produce at least one
   service, a Virtual Leased Line.  A recommended codepoint for this PHB
   is given.

   A pdf version of this document is available at
   ftp://ftp.ee.lbl.gov/papers/ef_phb.pdf

1.  Introduction

   Network nodes that implement the differentiated services enhancements
   to IP use a codepoint in the IP header to select a per-hop behavior
   (PHB) as the specific forwarding treatment for that packet [RFC2474,
   RFC2475].  This memo describes a particular PHB called expedited
   forwarding (EF). The EF PHB can be used to build a low loss, low
   latency, low jitter, assured bandwidth, end-to-end service through DS
   domains.  Such a service appears to the endpoints like a point-to-
   point connection or a "virtual leased line".  This service has also
   been described as Premium service [2BIT].





Jacobson, et al.            Standards Track                     [Page 1]

RFC 2598              An Expedited Forwarding PHB              June 1999


   Loss, latency and jitter are all due to the queues traffic
   experiences while transiting the network.  Therefore providing low
   loss, latency and jitter for some traffic aggregate means ensuring
   that the aggregate sees no (or very small) queues. Queues arise when
   (short-term) traffic arrival rate exceeds departure rate at some
   node.  Thus a service that ensures no queues for some aggregate is
   equivalent to bounding rates such that, at every transit node, the
   aggregate's maximum arrival rate is less than that aggregate's
   minimum departure rate.

   Creating such a service has two parts:

      1) Configuring nodes so that the aggregate has a well-defined
         minimum departure rate. ("Well-defined" means independent of
         the dynamic state of the node.  In particular, independent of
         the intensity of other traffic at the node.)

      2) Conditioning the aggregate (via policing and shaping) so that
         its arrival rate at any node is always less than that node's
         configured minimum departure rate.

   The EF PHB provides the first part of the service.  The network
   boundary traffic conditioners described in [RFC2475] provide the
   second part.

   The EF PHB is not a mandatory part of the Differentiated Services
   architecture, i.e., a node is not required to implement the EF PHB in
   order to be considered DS-compliant.  However, when a DS-compliant
   node claims to implement the EF PHB, the implementation must conform
   to the specification given in this document.

   The next sections describe the EF PHB in detail and give examples of
   how it might be implemented.  The keywords "MUST", "MUST NOT",
   "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this
   document are to be interpreted as described in [Bradner97].

2. Description of EF per-hop behavior

   The EF PHB is defined as a forwarding treatment for a particular
   diffserv aggregate where the departure rate of the aggregate's
   packets from any diffserv node must equal or exceed a configurable
   rate.  The EF traffic SHOULD receive this rate independent of the
   intensity of any other traffic attempting to transit the node.  It
   SHOULD average at least the configured rate when measured over any
   time interval equal to or longer than the time it takes to send an
   output link MTU sized packet at the configured rate.  (Behavior at
   time scales shorter than a packet time at the configured rate is




Jacobson, et al.            Standards Track                     [Page 2]

RFC 2598              An Expedited Forwarding PHB              June 1999


   deliberately not specified.) The configured minimum rate MUST be
   settable by a network administrator (using whatever mechanism the
   node supports for non-volatile configuration).

   If the EF PHB is implemented by a mechanism that allows unlimited
   preemption of other traffic (e.g., a priority queue), the
   implementation MUST include some means to limit the damage EF traffic
   could inflict on other traffic (e.g., a token bucket rate limiter).
   Traffic that exceeds this limit MUST be discarded. This maximum EF
   rate, and burst size if appropriate, MUST be settable by a network
   administrator (using whatever mechanism the node supports for non-
   volatile configuration). The minimum and maximum rates may be the
   same and configured by a single parameter.

   The Appendix describes how this PHB can be used to construct end-to-
   end services.

2.2 Example Mechanisms to Implement the EF PHB

   Several types of queue scheduling mechanisms may be employed to
   deliver the forwarding behavior described in section 2.1 and thus
   implement the EF PHB. A simple priority queue will give the
   appropriate behavior as long as there is no higher priority queue
   that could preempt the EF for more than a packet time at the
   configured rate.  (This could be accomplished by having a rate
   policer such as a token bucket associated with each priority queue to
   bound how much the queue can starve other traffic.)

   It's also possible to use a single queue in a group of queues
   serviced by a weighted round robin scheduler where the share of the
   output bandwidth assigned to the EF queue is equal to the configured
   rate.  This could be implemented, for example, using one PHB of a
   Class Selector Compliant set of PHBs [RFC2474].

   Another possible implementation is a CBQ [CBQ] scheduler that gives
   the EF queue priority up to the configured rate.

   All of these mechanisms have the basic properties required for the EF
   PHB though different choices result in different ancillary behavior
   such as jitter seen by individual microflows. See Appendix A.3 for
   simulations that quantify some of these differences.

2.3 Recommended codepoint for this PHB

   Codepoint 101110 is recommended for the EF PHB.






Jacobson, et al.            Standards Track                     [Page 3]

RFC 2598              An Expedited Forwarding PHB              June 1999


2.4 Mutability

   Packets marked for EF PHB MAY be remarked at a DS domain boundary
   only to other codepoints that satisfy the EF PHB.  Packets marked for
   EF PHBs SHOULD NOT be demoted or promoted to another PHB by a DS
   domain.

2.5 Tunneling

   When EF packets are tunneled, the tunneling packets must be marked as
   EF.

2.6 Interaction with other PHBs

   Other PHBs and PHB groups may be deployed in the same DS node or
   domain with the EF PHB as long as the requirement of section 2.1 is
   met.

3. Security Considerations

   To protect itself against denial of service attacks, the edge of a DS
   domain MUST strictly police all EF marked packets to a rate
   negotiated with the adjacent upstream domain.  (This rate must be <=
   the EF PHB configured rate.)  Packets in excess of the negotiated
   rate MUST be dropped.  If two adjacent domains have not negotiated an
   EF rate, the downstream domain MUST use 0 as the rate (i.e., drop all
   EF marked packets).

   Since the end-to-end premium service constructed from the EF PHB
   requires that the upstream domain police and shape EF marked traffic
   to meet the rate negotiated with the downstream domain, the
   downstream domain's policer should never have to drop packets.  Thus
   these drops SHOULD be noted (e.g., via SNMP traps) as possible
   security violations or serious misconfiguration. Similarly, since the
   aggregate EF traffic rate is constrained at every interior node, the
   EF queue should never overflow so if it does the drops SHOULD be
   noted as possible attacks or serious misconfiguration.

4. IANA Considerations

   This document allocates one codepoint, 101110, in Pool 1 of the code
   space defined by [RFC2474].









Jacobson, et al.            Standards Track                     [Page 4]

RFC 2598              An Expedited Forwarding PHB              June 1999


5. References

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

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

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

   [2BIT]      K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit
               Differentiated Services Architecture for the Internet",
               Work in Progress, ftp://ftp.ee.lbl.gov/papers/dsarch.pdf

   [CBQ]       S. Floyd and V. Jacobson, "Link-sharing and Resource
               Management Models for Packet Networks", IEEE/ACM
               Transactions on Networking, Vol. 3 no. 4, pp. 365-386,
               August 1995.

   [RFC2415]   Poduri, K. and K. Nichols, "Simulation Studies of
               Increased Initial TCP Window Size", RFC 2415, September
               1998.

   [LCN]       K. Nichols, "Improving Network Simulation with Feedback",
               Proceedings of LCN '98, October 1998.






















Jacobson, et al.            Standards Track                     [Page 5]

RFC 2598              An Expedited Forwarding PHB              June 1999


6. Authors' Addresses

   Van Jacobson
   Cisco Systems, Inc
   170 W. Tasman Drive
   San Jose, CA 95134-1706

   EMail: [e-mail]


   Kathleen Nichols
   Cisco Systems, Inc
   170 W. Tasman Drive
   San Jose, CA 95134-1706

   EMail: [e-mail]


   Kedarnath Poduri
   Bay Networks, Inc.
   4401 Great America Parkway
   Santa Clara, CA 95052-8185

   EMail: [e-mail]