A Delay Bound alternative revision of RFC 2598
RFC 3248

Document Type RFC - Informational (March 2002; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state WG Document
Document shepherd No shepherd assigned
IESG IESG state RFC 3248 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
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]
Show full document text