[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                          Marty Borden,
Differentiated Services Working Group                    Bay Networks.
Internet Draft                                      Christopher White,
Expires in six months                            Omnia Communications.
                                                          August, 1998

                          Management of PHBs

Status of this Memo

   This document is a submission to the IETF Differentiated Services
   (DiffServ) Working Group.  Comments are solicited and should be
   addressed to the working group mailing list or to the editor.

   This document is an Internet-Draft.  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 Drafts.

   Internet-Drafts draft documents are valid for a maximum of six
   months and may be updated, replaced, or obsolete 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

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).

   Distribution of this memo is unlimited.


   The DiffServ Working Group will produce PHBs (Per Hop Behaviors)
   used to provide differentiated services.  Some of these are to be
   standardized, others may have widespread use and still others may
   remain experimental.  The encoding of the PHB into a codepoint of
   the DS Field will not be standardized, except for the legacy,
   precedence PHBs.  Therefore a method is needed to coordinate the
   use of PHBs and codepoints, even if only for the purpose of
   discussing them.  This draft addresses this coordination issue.

                                                              [Page 1]

Internet Draft         Diffserv PHB Management            August, 1998

Table of Contents

1.Introduction                                                      2
2.Terminology and Notations Used                                    3
3.Enumerated PHBs                                                   3
 3.1 Historical PHBs                                                4
 3.2 Publication of PHB values                                      5
 3.3 Local or Private PHBs                                          5
4.Exchange of PHB Information                                       5
5.Security Considerations                                           7
6.References                                                        7
7.Authors' Addresses                                                7

1. Introduction

   In the differentiated services architecture [ARCH], services are
   built up from the building blocks of per hop behaviors (PHBs).  Any
   PHB is the externally observable forwarding behavior applied at a
   DS capable node to a stream of packets that have a particular value
   in the bits of the DS field (DS codepoint).

   PHBs can also be grouped when it is necessary to describe the
   several forwarding behaviors simultaneously with respect to some
   common constraints.

   Each PHB or PHB group thus corresponds to a subset of particular
   bit patterns in the DS field.  It is not desirable, however, to
   rigidly map PHBs to codepoints.  On the contrary, there is a desire
   to have complete flexibility in this correspondence between
   behaviors and codepoints.  Such flexibility is useful in more than
   one way.  First, our understanding of good choices for PHBs is only
   beginning and allocation of DS codepoints for PHBs is premature and
   would possibly be limited in the future.  Secondly, even after our
   understanding of PHBs matures, it is quite possible that different
   providers will deem it useful to use quite different sets of PHBs.
   If these sets are moderately large then they could exhaust the
   corresponding sets of potential codepoints and no fixed mapping
   would suffice.

   For these reasons, we propose that instead of enumerating the
   codepoints and rigidly assigning PHBs to them, we enumerate the
   PHBs, as they become defined, and allow the mapping of PHBs to
   codepoints to be done within each DS domain.

   As long as the enumeration space contains a large number of values,
   there is no danger of running out of space to list the PHB values.
   The PHB values can be made public for maximum interoperability.
   Section 3 discusses the PHB enumeration.

                                                              [Page 2]

Internet Draft         Diffserv PHB Management            August, 1998

   With the added freedom of flexibly mapping PHBs to codepoints comes
   the additional work of reaching agreements between adjacent DS
   domains as to the interpretation and translation of codepoints.  As
   long as the DS domains use the enumerated PHBs, they have a common
   language for communicating per hop behaviors.  What is needed is a
   method for translating one set of codepoints to another.  This is
   discussed in section 4.

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

2. Terminology and Notations Used

   We will use the following terminology:

       Boundary Link: A network link between two DS domains.  The link
                      connects the exit boundary node of one domain
                      with the entry boundary node of the other.

       PHB value:     The unique identifier used to enumerate PHBs.

       PHB set:       A set of PHBs identified by PHB values.

   The following notation is used to represent the PHBs and codepoints

       PHBs(x)        The set of PHBs supported by a domain x.

       CP(x,phb)      The value of the mapping from a PHB value to
                      codepoints for use within domain x:  phb is an
                      element of PHBs(x); CP(x,phb) is a set of

3. Enumerated PHBs

   Each PHB is assigned 32-bit unsigned integer, called the PHB value.
   This numerical value is not of significance beyond its use in

   We envision that a router will maintain the equivalent of a table
   such as

                                                              [Page 3]

Internet Draft         Diffserv PHB Management            August, 1998

     PHB value  |  DS Codepoint
     ...        |   ...
     370        |  101000
     371        |  101010
     371        |  101011
     ...        |   ...

   The same PHB value could be listed several times in the table:
   different codepoints MAY represent the same PHB.  This allows an
   entire set of codepoints to be recognized as indicating the same
   per hop behavior.  This could be useful, for example, in some
   implementations that use a portion of the bit pattern to recognize
   a PHB and the remainder of the bit field to do any proprietary

   The same DS codepoint MAY be listed with different PHBs.  At first
   this might not seem correct, as different PHBs will receive the
   same forwarding behavior based on them having the same codepoint.
   However it really is necessary to allow this.  For example, the
   default, best-effort behavior and the lowest level precedence
   behavior might be mapped to the same codepoint and receive the same
   forwarding treatment.

   The above considerations show that the table is not the
   representation of a function between PHBs and Codepoints.  What can
   be said is that there is a function CP() that maps PHBs to *sets*
   of codepoints.  Such a mapping is domain specific, so that in
   domain x (say) we might have CP(x,371) = {101010, 101011}, as
   indicated in the table above.

   It is important to note that the table is not used in the
   forwarding path, but is used to configure the forwarding path and
   its behavior.

3.1 Historical PHBs

   The default PHB is the behavior corresponding to the best-effort
   forwarding of today's routers [Header].  It is assigned the PHB
   value 0.

   We assume that the default PHB is in PHBs(x) for any domain x.

   The 8 precedence PHBs [Header] are assigned the values 1 through 8.
   The lowest precedence, corresponding to bit pattern 000, is
   assigned the value 1; in general bit pattern b (interpreted in
   network order) is assigned numerical value b+1.

                                                              [Page 4]

Internet Draft         Diffserv PHB Management            August, 1998

3.2 Publication of PHB values

   To facilitate interoperability, in addition to the standardization
   guidelines in [Header], PHBs MUST, as part of their proposal for
   standardization, specify a PHB value, unique to the PHB.

   A service to be offered by the Diffserv working group is to publish
   the values of PHBs on its web page
   http://www.ietf.org/html.charters/diffserv-charter.html. We
   anticipate the assignment of PHB values to be done serially.

   PHBs that are standard or proposed for standardization MUST be
   published on the working group web page.  PHBs that may be widely
   used or for which interoperability is desirable SHOULD be published
   at the working group web page.  Other PHBs MAY be published on the
   web page.

3.3 Local or Private PHBs

   It is possible that a provider may wish to use some PHBs privately,
   for its own purposes.  The associated PHB values need not be
   published but MUST NOT be the same value as any published PHB
   values.  In the future, we may find use of a protocol to exchange
   PHB information, and conflicting interpretation of PHB values would
   unnecessarily complicate any such protocol.  Private PHBs SHOULD be
   assigned values at least 2**30.  There are an ample number of such
   PHB values and they are well outside of the expected range of
   enumerated, public PHB values.

4. Exchange of PHB Information

   We consider the problem of interoperation between 2 DS domains, x
   and y, say.  To solve this problem, x and y need to reach an
   agreement on the support of PHBs and the usage of codepoints.  This
   involves two agreements: how to handle flows from x into y and how
   to handle flows from y into x.  To describe what needs to be done,
   it is sufficient to explain only one of these.

   Consider the treatment of traffic from x into y.  Each packet
   that crosses the boundary link has some associated phb in PHBs(x),
   although the traffic on this boundary link may correspond to a
   strict subset of PHBs(x).  When x enters agreement with y, it is
   only necessary to deal with forwarding traffic that will actually
   traverse the boundary link.  There are three possible ways to
   transform the behavior given to the packet as it enters domain y.

                                                              [Page 5]

Internet Draft         Diffserv PHB Management            August, 1998

   (1) The phb in PHBs(x) is also in PHBs(y) and y agrees to support
       this behavior on packets received from x.  In this case a
       mapping from CP(x, phb) to CP(y, phb) is required.  This
       mapping could be the trivial identity mapping if x and y use
       the same codepoints for phb.  It could, however, be quite
       complicated to determine the mapping when the CP()'s are sets.
       For example, if CP(x, phb) = {011101, 011010, 001011} and
       CP(y, phb) = {011111, 101011}, some detailed discussions would
       probably be necessary in order to decide the best mapping.

       Once a mapping is determined for each phb, it must be decided
       whether x or y is responsible to perform the manipulation of
       the DS field.

   (2) The phb in PHBs(x) is either in PHBs(y) but y will not support
       this behavior in traffic from x, or phb is a behavior outside
       of PHBs(y). Suppose further that x and y agree that a
       substitute phb' in PHBs(y) is acceptable downstream behavior
       for phb.  Of course care must be taken to use a substitute
       that provides a per hop behavior at least as good as phb or
       very similar to phb since this decision may affect traffic
       from upstream domains as well.  Since this transformation of
       phb to phb' is not invertible, there no recovery of phb
       possible downstream and information is lost.

       In this case we require a mapping between CP(x, phb) and CP(y,
       phb'), and a decision as to whether x or y will do the mapping
       of the DS field.

   (3) If neither of the above 2 cases applies, then y has no option
       other than to classify such incoming traffic from x as

   As mentioned above, we would need to make the mapping decisions for
   traffic in each direction.  These decisions may be done manually
   via operator intervention, by a dynamic protocol between
   neighboring domains, or by a combination of the two.  Any
   algorithmic approach for assigning codepoints is more complicated
   when the CP() functions yield sets rather than individual
   codepoints and it would be nearly impossible to guess the
   operator's intent unless these sets have a clearly defined
   structure.  Work in this direction could be continued if there is
   such structure and sufficient interest.

                                                              [Page 6]

Internet Draft         Diffserv PHB Management            August, 1998

5. Security Considerations

   Security considerations for Diffserv in general are discussed in
   [Header] and [Arch].  It is specifically of concern with respect to
   this draft that the configuration of the translation of codepoints
   be done in a secure manner by authorized entities in a manner
   agreed to by adjacent domains.

6. References

   [Header]     Nichols, Blake, Baker and Black, "Definition of the
                Differentiated Services Field (DS Field) in the IPv4
                and IPv6 Headers", <draft-ietf-diffserv-header-

   [Arch]       Black, et. al, "An Architecture for Differentiated
                Services," <draft-ietf-diffserv-arch-00.txt>.

   [RFC2119]    Bradner, "Key words for use in RFCs to Indicate
                Requirement Levels."

7. Authors' Addresses

     Marty Borden
     Bay Networks, Inc.
     +1 978-916-4578

     Christopher White
     Omnia Communications, Inc.
     +1 508-229-8444

                                                              [Page 7]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/