[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 rfc3248                                                 
Internet-Draft                                 EF RESOLVE DESIGN TEAM
                                                   (Grenville Armitage)
                                                       (Alessio Casati)
                                                        (Jon Crowcroft)
                                                         (Joel Halpern)
                                                        (Brijesh Kumar)
                                                      (John Schnizlein)

                                                    November 12th, 2000

           A revised expression of the Expedited Forwarding PHB

Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-

    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

     The list of Internet-Draft Shadow Directories can be accessed at

    This document was submitted to the IETF Differentiated Services
    (DiffServ) WG.  Publication of this document does not imply
    acceptance by the DiffServ WG of any ideas expressed within.
    Comments should be submitted to the diffserv@ietf.org mailing list.

    Distribution of this memo is unlimited.


    RFC 2598 is the DiffServ working group's current 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, additional issues were raised with the text in RFC 2598
    [2]. An 'EF design team' was formed after the Pittsburgh IETF meeting

EFRESOLVE.                Expires May 16, 2000                   [Page 1]

Internet Draft   <draft-ietf-diffserv-efresolve-00.txt>    Nov. 16, 2000

    to synthesize a new expression of the EF PHB. This Internet Draft
    captures our feedback to the DiffServ WG on a proposed revision to
    the EF PHB definition. A formal revision to RFC 2598 will be derived
    from this document.

Specification of Requirements

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    document are to be interpreted as described in RFC 2119 [3].

1 Introduction

    RFC 2598 is the Differentiated Services (DiffServ) working group's
    current 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, additional issues were raised with
    the text in RFC 2598 [2]. An 'EF design team' was formed after the
    Pittsburgh IETF meeting to synthesize a new expression of the EF PHB.
    This Internet Draft captures our feedback to the DiffServ WG on a
    proposed revision to the EF PHB definition.

    A formal revision to RFC 2598 will be derived from this document.

    Section 2 covers the minimum, necessary and sufficient description of
    what qualifies as 'EF' 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 Expedited Forwarding

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

    When a DS-compliant node claims to implement the EF PHB, the
    implementation MUST conform to the specification given in this
    document. However, the EF PHB is not a mandatory part of the
    Differentiated Services architecture - a node is NOT REQUIRED to
    implement the EF PHB in order to be considered DS-compliant.

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

2.1 Goal and Scope of EF

EFRESOLVE.                Expires May 16, 2000                   [Page 2]

Internet Draft   <draft-ietf-diffserv-efresolve-00.txt>    Nov. 16, 2000

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

    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 EF PHB definition.  Such rules
    MUST be defined in any per-domain behaviors (PDBs) composed from the
    EF PHB.

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

    If more EF traffic arrives than is acceptable, the device is NOT
    REQUIRED to deliver the EF behavior. However, although the original
    source of EF 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 an EF implementation SHOULD have some
    tolerance for burstiness - the ability to provide EF behavior even
    when the arrival rate exceeds the rate limit R.

    Different EF 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
    EF behavior. However, since the goal of characterizing burstiness is
    to allow useful comparison of EF implementations, vendors and users
    of EF implementations MAY choose to utilize other burstiness

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

2.2 Description of EF 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.

    The crux of this definition is that the difference in time between

EFRESOLVE.                Expires May 16, 2000                   [Page 3]

Internet Draft   <draft-ietf-diffserv-efresolve-00.txt>    Nov. 16, 2000

    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 EF
    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 EF traffic arriving at the device on
    other ports, and all non-EF traffic arriving at the device on any

    EF 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 EF 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 EF behavior

    An implementation need not conform to the EF 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 EF 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 EF behavior.

    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 EF behavior, and the

EFRESOLVE.                Expires May 16, 2000                   [Page 4]

Internet Draft   <draft-ietf-diffserv-efresolve-00.txt>    Nov. 16, 2000

    conditions under which it might do so, is outside the scope of this

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

    This document does not specify any requirements on an EF
    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 EF behavior

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

    By default a DSCP of 101110 indicates that EF 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 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

3.2 Tunneling

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

3.3 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 is

3.4 Output Rate not specified

    The definition of EF behavior given in section 2 is quite explicitly
    given in terms of input rate R and output delay variation D(i) -

EFRESOLVE.                Expires May 16, 2000                   [Page 5]

Internet Draft   <draft-ietf-diffserv-efresolve-00.txt>    Nov. 16, 2000

    E(i). A scheduler's output rate does not need to be specified, since
    it will be whatever is needed to achieve the target delay variation

3.5 Jitter

    Jitter is not the bounded parameter in EF 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, EF
    behavior aims to bound a related but different parameter - the
    variation in delay between the time packets would ideally depart,
    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 EF
    traffic is converging on a single output port from multiple input
    ports.  When evaluating the ability of an EF device to offer EF
    behavior to traffic arriving on one port, EF traffic arriving on
    other ports is factored in as competing traffic.

    When considering EF traffic from a single input that is leaving via
    multiple ports, it is clear that the behavior is no worse than if all
    of the traffic could be leaving through each one of those ports
    individually (subject to limits on how much is permitted).

3.7 Fragmentation and Rate

    Where an ingress link has an MTU higher than that of an egress link,
    it is conceivable packets may be fragmented as they pass through a
    Diffserv hop. However, the unpredictability of fragmentation is
    significantly counter to the goal of providing controllable QoS.
    Therefore we assume that fragmentation of EF packets is being avoided
    (either through some form of Path MTU discovery, or configuration),
    and does not need to be specifically considered in the EF behavior

3.8 Interference with other traffic

    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. This will be reflected in the EF
    device's burst tolerance described in section 2.1.

3.9 Micro flow awareness

EFRESOLVE.                Expires May 16, 2000                   [Page 6]

Internet Draft   <draft-ietf-diffserv-efresolve-00.txt>    Nov. 16, 2000

    Some EF implementations may choose to provide queuing and scheduling
    at a finer granularity (for example, per micro flow) than is
    indicated solely by the packet's DSCP. Such behavior is NOT precluded
    by the EF PHB definition. However, such behavior is also NOT part of
    the EF PHB definition. Vendors are free to characterize and publicize
    the additional per micro flow capabilities of their EF
    implementations as they see fit.

3.10 Arrival rate 'R'

    In the absence of additional information, R is assumed to be limited
    by the slowest interface on the device.

    In addition, an EF device may be characterized by different values of
    R for different traffic flow scenarios (for example, for traffic
    aimed at different ports, total incoming R, and possibly total per
    output port incoming R across all incoming interfaces).

4. IANA Considerations

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

5. Conclusion.

    This document defines EF behavior in terms of a bound on delay
    variation for traffic streams that are rate shaped on ingress to a DS
    domain. Two parameters - capped arrival rate (R) and a 'score' (S)
    are defined and related to the target delay variation bound.  All
    claims of EF 'conformance' for specific implementations of EF
    behavior are made with respect to particular values for R, S, and the
    implementation's ability to tolerate small amounts of burstiness in
    the arriving EF traffic stream.

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 (for example, some value
    less than or equal to the capped arrival rate R).  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 PDBs constructed from the EF PHB will require 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

EFRESOLVE.                Expires May 16, 2000                   [Page 7]

Internet Draft   <draft-ietf-diffserv-efresolve-00.txt>    Nov. 16, 2000

    never have to drop packets.  Thus these drops SHOULD be noted (e.g.,
    via SNMP traps) as possible security violations or serious

    Overflow events on an EF queue MAY also be logged as indicating
    possible denial of service attacks or serious network


    This draft is the product of the EF Resolve design team, and builds
    almost entirely on the works of V. Jacobson, K. Nichols, K. Poduri
    [1] and A. Charny, F. Baker, J. Bennett, K. Benson, J.-Y. Le Boudec,
    A. Chiu, W. Courtney, B. Davie, S. Davari, V. Firou, C. Kalmanek,
    K.K. Ramakrishnan, and D. Stiliadis [2].  Non-contentious text (such
    as the use of EF with tunnels, the security considerations, etc) were
    drawn directly from RFC 2598.

EF Design Team Members

    Grenville Armitage
      Rm A234, 3180 Porter Drive
      Palo Alto, CA 94061
      email: gja@lucent.com

    Brian E. Carpenter (team observer, WG co-chair)
      iCAIR, Suite 150
      1890 Maple Avenue
      Evanston IL 60201, USA
      email: brian@icair.org

    Alessio Casati
      Lucent Technologies
      Swindon, WI  SN5 7DJ  United Kingdom
      email: acasati@lucent.com

    Jon Crowcroft
      Department of Computer Science
      University College London
      Gower Street,
      London WC1E 6BT, UK
      email: J.Crowcroft@cs.ucl.ac.uk

    Joel M. Halpern
      Longitude Systems, Inc.
      15000 Conference Center Drive

EFRESOLVE.                Expires May 16, 2000                   [Page 8]

Internet Draft   <draft-ietf-diffserv-efresolve-00.txt>    Nov. 16, 2000

      Chantilly, VA 20151
      email: joel@longsys.com

    Brijesh Kumar
      Ennovate Networks
      email: bkumar@ennovatenetworks.com

    John Schnizlein
      Cisco Systems
      9123 Loughran Road
      Fort Washington, MD 20744
      email: john.schnizlein@cisco.com

Intellectual Properties Considerations



    [1] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding
    PHB", RFC 2598, June 1999

    [2] A Charny, ed. "EF PHB Redefined", INTERNET DRAFT <draft-charny-
    ef-definition-00.txt> (work in progress), July 2000

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

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

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

EFRESOLVE.                Expires May 16, 2000                   [Page 9]