rfc3248.txt

RFC 的详细文档！

Network Working Group                                        G. Armitage
Request for Comments: 3248            Swinburne University of Technology
Category: Informational                                     B. Carpenter
                                                                    IBM
                                                               A. Casati
                                                     Lucent Technologies
                                                            J. Crowcroft
                                                 University of Cambridge
                                                              J. Halpern
                                                              Consultant
                                                                B. Kumar
                                                    Corona Networks Inc.
                                                           J. Schnizlein
                                                           Cisco Systems
                                                              March 2002


             A Delay Bound alternative revision of RFC 2598

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   For historical interest, this document captures the EF Design Team's
   proposed solution, preferred by the original authors of RFC 2598 but
   not adopted by the working group in December 2000.  The original
   definition of EF was based on comparison of forwarding on an unloaded
   network.  This experimental Delay Bound (DB) PHB requires a bound on
   the delay of packets due to other traffic in the network.  At the
   Pittsburgh IETF meeting in August 2000, the Differentiated Services
   working group faced serious questions regarding RFC 2598 - the
   group's standards track definition of the Expedited Forwarding (EF)
   Per Hop Behavior (PHB).  An 'EF Design Team' volunteered to develop a
   re-expression of RFC 2598, bearing in mind the issues raised in the
   DiffServ group.  At the San Diego IETF meeting in December 2000 the
   DiffServ working group decided to pursue an alternative re-expression
   of the EF PHB.






Armitage, et al.             Informational                      [Page 1]

RFC 3248      Delay Bound alternative revision of RFC 2598    March 2002


Specification of Requirements

   This document is for Informational purposes only.  If implementors
   choose to experiment with the DB PHB, key words "MUST", "MUST NOT",
   "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in
   RFC 2119 [3].

1 Introduction

   RFC 2598 was the Differentiated Services (DiffServ) working group's
   first standards track definition of the Expedited Forwarding (EF) Per
   Hop Behavior (PHB) [1].  As part of the DiffServ working group's
   ongoing refinement of the EF PHB, various issues were raised with the
   text in RFC 2598 [2].

   After the Pittsburgh IETF meeting in August 2000, a volunteer 'EF
   design team' was formed (the authors of this document) to propose a
   new expression of the EF PHB.  The remainder of this Informational
   document captures our feedback to the DiffServ working group at the
   San Diego IETF in December 2000.  Our solution focussed on a Delay
   Bound (DB) based re-expression of RFC 2598 which met the goals of RFC
   2598's original authors.  The DiffServ working group ultimately chose
   an alternative re-expression of the EF PHB text, developed by the
   authors of [2] and revised to additionally encompass our model
   described here.

   Our proposed Delay Bound solution is archived for historical
   interest.  Section 2 covers the minimum, necessary and sufficient
   description of what we believed qualifies as 'DB' behavior from a
   single node.  Section 3 then discusses a number of issues and
   assumptions made to support the definition in section 2.

2. Definition of Delay Bound forwarding

   For a traffic stream not exceeding a particular configured rate, the
   goal of the DB PHB is a strict bound on the delay variation of
   packets through a hop.

   This section will begin with the goals and necessary boundary
   conditions for DB behavior, then provide a descriptive definition of
   DB behavior itself, discuss what it means to conform to the DB
   definition, and assign the experimental DB PHB code point.








Armitage, et al.             Informational                      [Page 2]

RFC 3248      Delay Bound alternative revision of RFC 2598    March 2002


2.1 Goal and Scope of DB

   For a traffic stream not exceeding a configured rate the goal of the
   DB PHB is a strict bound on the delay variation of packets through a
   hop.

   Traffic MUST be policed and/or shaped at the source edge (for
   example, on ingress to the DS-domain as discussed in RFC 2475 [5]) in
   order to get such a bound.  However, specific policing and/or shaping
   rules are outside the scope of the DB PHB definition.  Such rules
   MUST be defined in any per-domain behaviors (PDBs) composed from the
   DB PHB.

   A device (hop) delivers DB behavior to appropriately marked traffic
   received on one or more interfaces (marking is specified in section
   2.4).  A device SHALL deliver the DB behavior on an interface to DB
   marked traffic meeting (i.e. less than or equal) a certain arrival
   rate limit R.

   If more DB traffic arrives than is acceptable, the device is NOT
   REQUIRED to deliver the DB behavior.  However, although the original
   source of DB traffic will be shaped, aggregation and upstream jitter
   ensure that the traffic arriving at any given hop cannot be assumed
   to be so shaped.  Thus a DB implementation SHOULD have some tolerance
   for burstiness - the ability to provide EF behavior even when the
   arrival rate exceeds the rate limit R.

   Different DB implementations are free to exhibit different tolerance
   to burstiness.  (Burstiness MAY be characterized in terms of the
   number of back-to-back wire-rate packets to which the hop can deliver
   DB behavior.  However, since the goal of characterizing burstiness is
   to allow useful comparison of DB implementations, vendors and users
   of DB implementations MAY choose to utilize other burstiness
   metrics.)

   The DB PHB definition does NOT mandate or recommend any particular
   method for achieving DB behavior.  Rather, the DB PHB definition
   identifies parameters that bound the operating range(s) over which an
   implementation can deliver DB behavior.  Implementors characterize
   their implementations using these parameters, while network designers
   and testers use these parameters to assess the utility of different
   DB implementations.

2.2 Description of DB behavior

   For simplicity the definition will be explained using an example
   where traffic arrives on only one interface and is destined for
   another (single) interface.



Armitage, et al.             Informational                      [Page 3]

RFC 3248      Delay Bound alternative revision of RFC 2598    March 2002


   The crux of this definition is that the difference in time between
   when a packet might have been delivered, and when it is delivered,
   will never exceed a specifiable bound.

   Given an acceptable (not exceeding arrival rate limit R) stream of DB
   packets arriving on an interface:

      There is a time sequence E(i) when these packets would be
      delivered at the output interface in the absence of competing
      traffic.  That is, E(i) are the earliest times that the packets
      could be delivered by the device.

      In the presence of competing traffic, the packets will be delayed
      to some later time D(i).

   Competing traffic includes all DB traffic arriving at the device on
   other ports, and all non-DB traffic arriving at the device on any
   port.

   DB is defined as the behavior which ensures, for all i, that:

      D(i) - E(i) <=  S * MTU/R.

   MTU is the maximum transmission unit (packet size) of the output.  R
   is the arrival rate that the DB device is prepared to accept on this
   interface.

   Note that D(i) and E(i) simply refer to the times of what can be
   thought of as "the same packet" under the two treatments (with and
   without competing traffic).

   The score, S, is a characteristic of the device at the rate, R, in
   order to meet this defined bound.  This score, preferably a small
   constant, depends on the scheduling mechanism and configuration of
   the device.

2.3 Conformance to DB behavior

   An implementation need not conform to the DB specification over an
   arbitrary range of parameter values.  Instead, implementations MUST
   specify the rates, R, and scores S, for which they claim conformance
   with the DB definition in section 2.2, and the implementation-
   specific configuration parameters needed to deliver conformant
   behavior.  An implementation SHOULD document the traffic burstiness
   it can tolerate while still providing DB behavior.






Armitage, et al.             Informational                      [Page 4]

RFC 3248      Delay Bound alternative revision of RFC 2598    March 2002


   The score, S, and configuration parameters depend on the
   implementation error from an ideal scheduler.  Discussion of the
   ability of any particular scheduler to provide DB behavior, and the
   conditions under which it might do so, is outside the scope of this
   document.

   The implementor MAY define additional constraints on the range of
   configurations in which DB behavior is delivered.  These constraints
   MAY include limits on the total DB traffic across the device, or
   total DB traffic targeted at a given interface from all inputs.

   This document does not specify any requirements on DB
   implementation's values for R, S, or tolerable burstiness.  These
   parameters will be bounded by real-world considerations such as the
   actual network being designed and the desired PDB.

2.4 Marking for DB behavior

   One or more DiffServ codepoint (DSCP) value may be used to indicate a
   requirement for DB behavior [4].

   By default we suggest an 'experimental' DSCP of 101111 be used to
   indicate that DB PHB is required.

3. Discussion

   This section discusses some issues that might not be immediately
   obvious from the definition in section 2.

3.1 Mutability

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

3.2 Tunneling

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

3.3 Interaction with other PHBs

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





Armitage, et al.             Informational                      [Page 5]

RFC 3248      Delay Bound alternative revision of RFC 2598    March 2002


3.4 Output Rate not specified

   The definition of DB behavior given in section 2 is quite explicitly
   given in terms of input rate R and output delay variation D(i) -
   E(i).  A scheduler's output rate does not need to be specified, since
   (by design) it will be whatever is needed to achieve the target delay
   variation bounds.

3.5 Jitter

   Jitter is not the bounded parameter in DB behavior.  Jitter can be
   understood in a number of ways, for example the variability in
   inter-packet times from one inter-packet interval to the next.
   However, DB behavior aims to bound a related but different parameter
   - the variation in delay between the time packets would depart in the
   absence of competing traffic, E(i), and when they would depart in the
   presence of competing traffic, D(i).

3.6 Multiple Inputs and/or Multiple Outputs

   The definition of 'competing traffic' in section 2.2 covers both the
   single input/single output case and the more general case where DB
   traffic is converging on a single output port from multiple input
   ports.  When evaluating the ability of an DB device to offer DB