TSVWG                                                       R. Geib, Ed.
Internet-Draft                                          Deutsche Telekom
Intended status: Informational                                  D. Black
Expires: June 7, September 10, 2015                              EMC Corporation
                                                        December 4, 2014
                                                           March 9, 2015

             DiffServ interconnection classes and practice
                 draft-ietf-tsvwg-diffserv-intercon-00
                 draft-ietf-tsvwg-diffserv-intercon-01

Abstract

   This document proposes a limited and well defined set of DiffServ PHBs and codepoints
   to be applied at (inter)connections of two separately administered
   and operated networks.  Many network providers operate MPLS using
   Treatment Aggregates for traffic marked with different DiffServ PHBs,
   and use MPLS for interconnection with other networks.  This document
   offers a simple interconnection approach that may simplify operation
   of DiffServ for network interconnection among providers. providers that use
   MPLS.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on June 7, September 10, 2015.

Copyright Notice

   Copyright (c) 2014 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Related work  . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Applicability Statement . . . . . . . . . . . . . . . . .   4
     1.3.  Document Organization . . . . . . . . . . . . . . . . . .   4
   2.  MPLS and the Short Pipe tunnel model  . . . . . . . . . . . .   5   4
   3.  An Interconnection class and codepoint scheme  Relationship to RFC 5127  . . . . . . . .   6 . . . . . . . . . .   5
     3.1.  RFC 5127 Background . . . . . . . . . . . . . . . . . . .   6
     3.2.  Differences from RFC 5127 . . . . . . . . . . . . . . . .   6
   4.  The DiffServ-Intercon Interconnection Classes . . . . . . . .   7
     4.1.  End-to-end QoS: PHB and DS CodePoint Transparency . . . .  11
     3.2.  12
     4.2.  Treatment of Network Control traffic at carrier
           interconnection interfaces  . . . . . . . . . . . . . . .  12
   4.  13
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   5.  14
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   6.  14
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   7.  14
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  14
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     7.2.  14
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  14  15
   Appendix A.  Annex  Appendix A Carrier interconnection related DiffServ
                aspects  . . . . . . . . . . . . . . . . . . . . . .  15  16
   Appendix B.  Annex 2  Appendix B The MPLS Short Pipe Model and IP traffic . .  17   18
   Appendix C.  Change log . . . . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21  22

1.  Introduction

   DiffServ has been deployed in many networks.  As described by section
   2.3.4.2 of RFC 2475, remarking of packets at domain boundaries is a
   DiffServ feature [RFC2475].  This draft proposes a set of standard
   QoS classes and code points at interconnection points to which and
   from which locally used classes and code points should be mapped.

   RFC2474 specifies the DiffServ Codepoint Field [RFC2474].
   Differentiated treatment is based on the specific DSCP.  Once set, it
   may change.  If traffic marked with unknown or unexpected DSCPs is
   received, RFC2474 recommends forwarding that traffic with default
   (best effort) treatment without changing the DSCP markings.  Many
   networks do not follow this recommendation, and instead remark
   unknown or unexpected DSCPs to the zero DSCP upon receipt for
   consistency with default (best effort) forwarding.

   Many providers operate MPLS-based backbones that employ backbone
   traffic engineering forwarding in accordance with
   the guidance in RFC 2475 [RFC2474] to ensure that if a major link, switch, or router
   fails, the result will be appropriate DSCPs
   are used within a routed DiffServ domain.

   This document is motivated by requirements for IP network
   interconnection with DiffServ support among providers that continues operate
   MPLS in their backbones, but is applicable to meet its
   Service Level Agreements (SLAs).  Based on that foundation,
   foundation, [RFC5127] introduces the concept of DiffServ Treatment
   Aggregates, which enable traffic marked with multiple DSCPs to be
   forwarded in a single MPLS Traffic Class (TC).  Like RFC 5127, this
   document assumes robust provider backbone traffic engineering.

   RFC5127 recommends transmission of DSCPs as they are received.  This
   is not possible, if the receiving and the transmitting domains at a
   network interconnection use different DSCPs for the PHBs involved.

   This document is motivated by requirements for IP network
   interconnection with DiffServ support among providers that operate
   MPLS in their backbones, but is applicable to other technologies.
   The operational simplifications and methods in this document help
   align IP other technologies.
   The operational simplifications and methods in this document help
   align IP DiffServ functionality with MPLS limitations, particularly
   when MPLS penultimate hop popping is used.  That is an important
   reason why this document specifies 4 interconnection Treatment
   Aggregates.  Limiting limitations; further,
   limiting DiffServ to a small number of Treatment Aggregates can help ensure that
   enable network traffic leaves to leave a network with the same DSCPs that it
   was received with.  The approach proposed here may be
   extended by operators or future specifications. with, even if a different DSCP is used within the
   network, thus providing an opportunity to extend consistent QoS
   treatment across network boundaries.

   In isolation, use of standard interconnection PHBs and DSCPs may
   appear to be additional effort for a network operator.  The primary
   offsetting benefit is that the mapping from or to the interconnection
   PHBs and DSCPs is specified once for all of the interconnections to
   other networks that can use this approach.  Otherwise, the PHBs and
   DSCPs have to be negotiated and configured independently for each
   network interconnection, which has poor scaling properties.  Further,
   end-to-end QoS treatment is more likely to result when an
   interconnection code point scheme is used because traffic is remarked
   to the same PHBs at all network interconnections.  This document
   supports
   envisions one-to-one DSCP remarking at network interconnections (not
   n DSCP to one DSCP remarking).

   The example given in RFC 5127 on aggregation of DiffServ service
   classes uses 4 Treatment Aggregates,

   In addition to the standard interconnecting PHBs and this document does likewise
   because:

   o  The available coding space DSCPs,
   interconnecting operators need to further agree on the tunneling
   technology used for carrying QoS information interconnection (e.g.,
      DiffServ PHB) in MPLS MPLS, if used) and Ethernet is only 3 bits in size, control
   or mitigate the impacts of tunneling on reliability and is
      intended for more than just QoS purposes (see e.g.  [RFC5129]).

   o  There should be unused codes for MTU.

1.1.  Related work

   In addition to the activities that triggered this work, there are
   additional RFCs and Internet-drafts that may benefit from an
   interconnection purposes.  This
      leaves space for future standards, for private bilateral
      agreements and for local use PHBs PHB and DSCPs.

   o  Migrations from one code point scheme DSCP scheme.  RFC 5160 suggests Meta-QoS-
   Classes to another may require spare enable deployment of standardized end to end QoS code points.

   RFC5127 provides recommendations on aggregation classes
   [RFC5160].  In private discussion, the authors of DSCP-marked
   traffic into MPLS Treatment Aggregates and offers a deployment
   example [RFC5127] that does not work for the MPLS Short Pipe model
   when RFC agree that model is used for ordinary network traffic.  This document
   supports
   the MPLS Short Pipe model for ordinary network traffic proposed interconnection class- and
   hence differs from the RFC5127 approach as follows:

   o  remarking codepoint scheme and its
   enablement of received DSCPs to domain internal DSCPs is standardised end to be
      expected for ordinary IP traffic at provider edges (and for outer
      headers of tunneled IP traffic).

   o  document follows RFC4594 in the proposed marking of provider
      Network Control traffic and expands RFC4594 end classes would complement their
   own work.

   Work on treatment signaling Class of CS6
      marked traffic Service at interconnection points (see section 3.2).

   This document interfaces by
   BGP [I-D.knoll-idr-cos-interconnect], [ID.idr-sla] is organized as follows: section 2 reviews beyond the MPLS
   Short Pipe tunnel model for DiffServ Tunnels [RFC3270]; effective
   support for that model is a crucial goal
   scope of this document.  Section 3
   introduces DiffServ interconnection Treatment Aggregates, plus draft.  When the
   PHBs and DSCPs that are mapped scheme in this document is used,
   signaled access to these Treatment Aggregates.
   Further, section 3 discusses treatment QoS classes may be of non-tunneled interest.  These two BGP
   documents focus on exchanging SLA and tunneled
   IP traffic conditioning parameters
   and MPLS VPN QoS assume that common PHBs identified by the signaled DSCPs have
   been established prior to BGP signaling of QoS.

1.2.  Applicability Statement

   This document is primarily applicable to use of Differentiated
   Services for interconnection traffic between networks, and in
   particular to interconnection of MPLS-based networks.  The approach
   described in this document is not intended for use within the
   interconnected (or other) networks, where the approach specified in
   RFC 5127 [RFC5127] is among the possible alternatives; see Section 3
   for further discussion.

   The Diffserv-Intercon approach described in this document simplifies
   IP based interconnection to domains operating the MPLS Short Pipe
   model to transport plain IP traffic terminating within or transiting
   through the receiving domain.  Transit traffic is reiceived and sent
   with the same PHB and DSCP.  Terminating traffic maintains the PHB
   with which it was received, however the DSCP may change.

1.3.  Document Organization

   This document is organized as follows: section 2 reviews the MPLS
   Short Pipe tunnel model for DiffServ Tunnels [RFC3270]; effective
   support for that model is a crucial goal of this document.  Section 3
   provides background on RFC 5127's approach to traffic class
   aggregation within a DiffServ network domain and explains why this
   document uses a somewhat different approach.  Section 4 introduces
   DiffServ interconnection Treatment Aggregates, plus the PHBs and
   DSCPs that are mapped to these Treatment Aggregates.  Further,
   section 4 discusses treatment of non-tunneled and tunneled IP traffic
   and MPLS VPN QoS aspects.  Finally Network Management PHB treatment
   is described.  Annex A discusses how domain internal IP
   layer QoS schemes impact interconnection.  Annex B describes the impact of the MPLS Short Pipe
   model (pen ultimate (penultimate hop popping) on QoS related IP interconnections.

1.1.  Related work

   In addition to

2.  MPLS and the activities that triggered this work, there are
   additional RFCs and Internet-drafts that may benefit from an
   interconnection PHB and DSCP scheme.  RFC 5160 suggests Meta-QoS-
   Classes to enable deployment of standardized end to end QoS classes
   [RFC5160].  In private discussion, the authors of that RFC agree that
   the proposed interconnection class- and codepoint scheme and its
   enablement of standardised end to end classes would complement their
   own work.

   Work on signaling Class of Service at interconnection interfaces by
   BGP [I-D.knoll-idr-cos-interconnect], [ID.idr-sla] is beyond the
   scope of this draft.  When the basic DiffServ elements for network
   interconnection are used as described in this document, signaled
   access to QoS classes may be of interest.  These two BGP documents
   focus on exchanging SLA and traffic conditioning parameters and
   assume that common PHBs identified by the signaled DSCPs have been
   established prior to BGP signaling of QoS.

2.  MPLS and the Short Pipe tunnel model

   The Pipe Short Pipe tunnel model

   The Pipe and Uniform models for Differentiated Services and Tunnels
   are defined in [RFC2983].  RFC3270 adds the MPLS Short Pipe model in
   order to support penultimate hop popping (PHP) of MPLS Labels,
   primarily for IP tunnels and VPNs.  The Short Pipe model and PHP have
   become popular with many network providers that operate MPLS networks
   and are now widely used for ordinary network to transport non-tunnelled IP traffic, not
   just traffic encapsulated in IP tunnels and VPNs.  This has important
   implications for DiffServ functionality in MPLS networks.

   RFC 2474's recommendation to forward traffic with unrecognized DSCPs
   with Default (best effort) service without rewriting the DSCP has
   proven to be a poor operational practice.  Network operation and
   management are simplified when there is a 1-1 match between the DSCP
   marked on the packet and the forwarding treatment (PHB) applied by
   network nodes.  When this is done, CS0 (the all-zero DSCP) is the
   only DSCP used for Default forwarding of best effort traffic, so a
   common practice is to use CS0 to remark traffic
   common practice is to use CS0 to remark traffic received with
   unrecognized or unsupported DSCPs at network edges.

   MPLS networks are more subtle in this regard, as it is possible to
   encode the provider's DSCP in the MPLS TC field and allow that to
   differ from the PHB indicated by the DSCP in the MPLS-encapsulated IP
   packet.  That would allow an unrecognized DSCP to be carried edge-to-
   edge over an MPLS network, because the effective DSCP used by the
   MPLS network would be encoded in the MPLS label TC field (and also
   carried edge-to-edge); this approach assumes that a provider MPLS
   label with the provider's TC field is present at all hops within the
   provider's network.

   The Short Pipe tunnel model and PHP violate that assumption because
   PHP pops and discards the MPLS provider label carrying the provider's
   TC field.  That discard occurs one hop upstream of the MPLS tunnel
   endpoint (which is usually at the network edge), resulting in no
   provider TC info being available at tunnel egress.  To ensure
   consistent handling of traffic at the tunnel egress, the DSCP field
   in the MPLS-encapsulated IP header has to contain a DSCP that is
   valid for the provider's network; propagating another DSCP edge-to-
   edge requires an IP tunnel of some form.  See Annex B for a more
   detailed discussion.

   If transport of a large number (much greater than 4) DSCPs is
   required across a network that supports this DiffServ interconnection
   scheme, a tunnel or VPN can be provisioned for this purpose, so that
   the inner IP header carries the DSCP that is to be preserved not to
   be changed.  From a network operations perspective, the customer
   equipment (CE) is the preferred location for tunnel termination,
   although a receiving domains Provider Edge router is another viable
   option.

3.  Relationship to RFC 5127

   This document draws heavily upon RFC 5127's approach to aggregation
   of DiffServ traffic classes for use within a network, but there are
   some important differences caused by the characteristics of network
   interconnects.

3.1.  RFC 5127 Background

   Many providers operate MPLS-based backbones that employ backbone
   traffic engineering to ensure that if a major link, switch, or router
   fails, the result will be a routed network that continues to meet its
   Service Level Agreements (SLAs).  Based on that foundation, [RFC5127]
   introduced the concept of DiffServ Treatment Aggregates, which enable
   traffic marked with multiple DSCPs to be forwarded in a single MPLS
   Traffic Class (TC) based on robust provider backbone traffic
   engineering.  This enables differentiated forwarding behaviors within
   a domain in a fashion that does not consume a large number of MPLS
   Traffic Classes.

   RFC 5127 provides an example aggregation of DiffServ service classes
   into 4 Treatment Aggregates.  A small number of aggregates are used
   because:

   o  The available coding space for carrying QoS information (e.g.,
      DiffServ PHB) in MPLS and Ethernet is only 3 bits in size, and is
      intended for more than just QoS purposes (see e.g.  [RFC5129]).

   o  There should be unused codes for interconnection purposes.  This
      leaves space for future standards, for private bilateral
      agreements and for local use PHBs and DSCPs.

   o  Migrations from one code point scheme to another may require spare
      QoS code points.

   RFC 5127 also follows RFC 2474 in recommending transmission of DSCPs
   through a network as they are received with
   unrecognized or unsupported DSCPs at the network edges.

   MPLS networks are more subtle in edge.

3.2.  Differences from RFC 5127

   Like RFC 5127, this regard, as it is possible to
   encode the provider's DSCP document also uses four traffic aggregates, but
   differs from RFC 5127 in three important ways:

   o  It follows RFC 2475 in allowing the MPLS TC field and allow that DSCPs used within a network to
      differ from the PHB indicated by the DSCP in the MPLS-encapsulated IP
   packet.  That would allow an unrecognized DSCP those to be carried edge-to-
   edge over an MPLS network, because the effective exchange traffic with other networks (at
      network edges), but provides support to restore ingress DSCP used by
      values when one of the
   MPLS network would be encoded recommended interconnect DSCPs in the MPLS label TC field (and also
   carried edge-to-edge); this approach
      draft is used.  This results in DSCP remarking at both network
      ingress and network egress, and this draft assumes that a provider MPLS
   label with the provider's TC field being present such
      remarking at network edges is possible for all hops within interface types.
      As discussed in Section 2 above, the provider's network.

   The MPLS Short Pipe tunnel model and PHP violate that assumption because
   PHP pops and discards the MPLS provider label carrying the provider's
   TC field.  That discard occurs one hop upstream
      effectively requires use of the MPLS tunnel
   endpoint, resulting in no provider TC info being available at tunnel
   egress.  Therefore the a DSCP field in that is locally valid for the MPLS-encapsulated IP header
   has
      network involved, leading to contain this remarking approach.

   o  It treats network control traffic as a special case.  Within a
      network, the CS6 DSCP is used for local network control traffic
      (routing protocols and OAM traffic that is valid essential for network
      operation administration, control and management) that may be
      destined for any node within the provider's network;
   propagating another DSCP edge-to-edge requires an IP tunnel of some
   form. network.  In contrast, network
      control traffic exchanged between networks (e.g., BGP traffic)
      usually terminates at or close to a network edge, and is not
      forwarded through the absence of IP tunneling (a common case for MPLS
   networks), network because it is not possible to pass all 64 possible DSCP values
   edge-to-edge across an MPLS network.  See Annex B for a more detailed
   discussion.

   If transport part of a large number (much greater than 4) DSCPs is
   required across a network that supports this DiffServ interconnection
   scheme, a tunnel internal
      routing or VPN can be provisioned OAM for this purpose, so that
   the inner IP header carries the DSCP that receiving network.  In addition, such
      traffic is unlikely to be preserved not covered by standard interconnection
      agreements; it is more likely to be changed.  From a specifically configured (e.g.,
      most networks impose on exchange of BGP for obvious reasons).  See
      Section 4.2 for further discussion.

   o  Because network operations perspective, the customer
   equipment (CE) control traffic is the preferred location for tunnel termination,
   although treated as a receiving domains Provider Edge router special case, a
      fourth traffic aggregate is another viable
   option.

3.  An defined for use at network
      interconnections to replace the Network Control aggregate in RFC
      5127.  Network Control traffic may still be exchanged across
      network interconnections as further discussed in Section 4.2

4.  The DiffServ-Intercon Interconnection class and codepoint scheme Classes

   At an interconnection, the networks involved need to agree on the
   PHBs used for interconnection and the specific DSCP for each PHB.
   This may involve remarking for the interconnection; such remarking is
   part of the DiffServ Architecture [RFC2475], at least for the network
   edge nodes involved in interconnection.  See Annex A for a more
   detailed discussion.  This draft proposes a
   standard interconnection set of 4 Treatment Aggregates with well-defined well-
   defined DSCPs to be aggregated by them.  A sending party remarks
   DSCPs from internal schemes to the interconnection code points.  The
   receiving party remarks DSCPs to her internal scheme.  The set of
   DSCPs and PHBs supported across the two interconnected domains and
   the treatment of PHBs and DSCPs not recognized by the receiving
   domain should be part of the interconnect SLA.

   RFC 5127's four treatment aggregates include a Network Control
   aggregate for routing protocols and OAM traffic that is essential for
   network operation administration, control and management.  Using this
   aggregate as one of the four in RFC 5127 implicitly assumes that
   network control traffic is forwarded in potential competition with
   all other network traffic, and hence DiffServ must favor such traffic
   (e.g., via use of the CS6 codepoint) for network stability.  That is
   a reasonable assumption for IP-based networks where routing and OAM
   protocols are mixed with all other types of network traffic;
   corporate networks are an example.

   In contrast, mixing of all traffic is not a reasonable assumption for
   MPLS-based provider or carrier networks, where customer traffic is
   usually segregated from network control (routing and OAM) traffic via
   other means, e.g., network control traffic use of separate LSPs that
   can be prioritized over customer LSPs (e.g., for VPN service) via
   other means.  This sort of segregation of network control traffic from
   customer traffic is also used for MPLS-based network
   interconnections.  In addition, many customers of a network provider
   do not exchange Network Control traffic (e.g., routing) with the
   network provider.  For these reasons, a separate Network Control
   traffic aggregate is not important for MPLS-based carrier or provider
   networks; when such traffic is not segregated from other traffic, it
   may reasonably share the Assured Elastic treatment aggregate (as RFC
   5127 suggests for a situation in which only three treatment
   aggregates are supported).

   In contrast, VoIP is emerging as a valuable and important class of
   network traffic for which network-provided QoS is crucial, as even
   minor glitches are immediately apparent to the humans involved in the
   conversation.

   For these reasons, the Diffserv Interconnect scheme in this document
   departs from apparent to the approach humans involved in RFC 5127 by not providing a Network
   Control traffic aggregate, and instead dedicating the fourth traffic
   aggregate for VoIP traffic.  Network Control traffic may still be
   exchanged across network interconnections, see Section 3.2 for
   further discussion.
   conversation.

   Similar approaches to use of a small number of traffic aggregates
   (including recognition of the importance of VoIP traffic) have been
   taken in related standards and recommendations from outside the IETF,
   e.g., Y.1566 [Y.1566], GSMA IR.34 [IR.34] andMEF23.1 [MEF23.1].

   The list of the four DiffServ Interconnect traffic aggregates
   follows, highlighting differences from RFC 5127 and the specific
   traffic classes from RFC 4594 that each class aggregates.

    Telephony Service Treatment Aggregate:  PHB EF, DSCP 101 110 and
           VOICE-ADMIT, DSCP 101100, see [RFC3246] , [RFC4594][RFC5865].
           This Treatment Aggregate corresponds to RFC 5127s real time
           Treatment Aggregate definition regarding the queuing, but it
           is restricted to transport Telephony Service Class traffic in
           the sense of RFC 4594.

   Bulk Real-Time Treatment Aggregate:  This Treatment Aggregate is
           designed to transport PHB AF41, DSCP 100 010 (the other AF4
           PHB group PHBs and DSCPs may be used for future extension of
           the set of DSCPs carried by this Treatment Aggregate).  This
           Treatment Aggregate is designed to transport the portions of
           RFC 5127's Real Time Treatment Aggregate, which consume large
           amounts of bandwidth, namely Broadcast Video, Real-Time
           Interactive and Multimedia Conferencing.  The treatment
           aggregate should be configured with a rate queue (which is in
           line with RFC 4594 for the mentioned traffic classes).  As
           compared to RFC 5127, the number of DSCPs has been reduced to
           one (initially) and the (initially).  The proposed queuing mechanism.  The
           latter mechanism is however in line
           with RFC4594. RFC4594 definitions for Broadcast Video and Real-Time
           Interactive.  If need for three-color marked Multimedia
           Conferencing traffic arises, AF42 and AF43 PHBs may be added.

   Assured Elastic Treatment Aggregate  This Treatment Aggregate
           consists of the entire AF3 PHB group AF3, i.e., DSCPs 011
           010, 011 100 and 011 110.  As compared to RFC5127, just the
           number of DSCPs, which has been reduced.  This document
           suggests to transport signaling marked by AF31.  RFC5127
           suggests to map Network Management traffic into this
           Treatment Aggregate, if no separate Network Control Treatment
           Aggregate is supported (for a more detailed discussion of
           Network Control PHB treatment see section 3.2).  GSMA IR.34
           proposes to transport signaling traffic by AF31 too.

   Default / Elastic Treatment Aggregate:   transports the default PHB,
           CS0 with DSCP 000 000.  RFC 5127 example refers to this
           Treatment Aggregate as Aggregate Elastic.  An important
           difference as compared to RFC5127 is that any traffic with
           unrecognized or unsupported DSCPs may be remarked to this
           DSCP.

   RFC 4594's Multimedia Streaming class has not been mapped to the
   above scheme.  By the time of writing, the most popular streaming
   applications use TCP transport and adapt picture quality in the case
   of congestion.  These applications are proprietary and still change
   behaviour frequently.  At this state,  Currently, the Bulk Real-Time Treatment
   Aggregate or the Bulk Real-Time Assured Elastic Treatment Aggregate may be a
   reasonable match.  NOTE: This paragraph would benefit from WG review
   and discussion.

   The overall approach to DSCP marking at network interconnections is
   illustrated by the following example.  Provider O and provider W are
   peered with provider T.  They have agreed upon a QoS interconnection
   SLA.

   Traffic of provider O terminates within provider Ts network, while
   provider W's traffic transits through the network of provider T to
   provider F.  Assume all providers to run their own internal codepoint
   schemes for a PHB groupwith group with properties of the DiffServ Intercon
   Assured Treatment Aggregate.

           Provider-O             Provider-W
           RFC5127                GSMA 34.1
               |                      |
          +----------+           +----------+
          |AF21, AF22|           | CS3, CS2 |
          +----------+           +----------+
               |                      |
               V                      V
           +++++++++              +++++++++
           |Rtr PrO|              |Rtr PrW|  Rtr Pr:
           +++++++++              +++++++++  Router Peering
               |        DiffServ      |
          +----------+           +----------+
          |AF31, AF32|           |AF31, AF32|
          +----------+           +----------+
               |        Intercon      |
               V                      V
           +++++++++                  |
           |RtrPrTI|------------------+
           +++++++++
               |     Provider-T domain
          +-----------+
          | MPLS TC 2 |
          | DSCP rew. |           rew. -> rewrite
          | AF21, AF22|
          +-----------+
             |      |  Local DSCPs Provider-T
             |      |  +----------+   +++++++++
             V      +->|AF21, AF22|->-|RtrDstH|
             |         +----------+   +++++++++
         +----------+                 RtrDst:
         |AF21, AF22|                 Router Destination
         +----------+
             |
          +++++++++
          |RtrPrTE|
          +++++++++
             |        DiffServ
         +----------+
         |AF31, AF32|
         +----------+
             |        Intercon
          +++++++++
          |RtrPrF|
          +++++++++
             |
         +----------+
         | CS4, CS3 |
         +----------+
             |
         Provider-F
         GSM IR.34

   DiffServ Intercon example

                                 Figure 1

   It is easily visible that all providers

   Providers only need to deploy internal DSCP to DiffServ Intercon DSCP
   mappings to exchange traffic in the desired classes.  Provider W has
   decided that the properties of his internal classes CS3 and CS2 are
   best met by the Diffserv Intercon Assured Elastic Treatment
   Aggregate, PHBs AF31 and AF32 respectively.  At the outgoing peering
   interface connecting provider W with provider T the former's peering
   router remarks CS3 traffic to AF31 and CS 2 CS2 traffic to CS32. AF32.  The
   domain internal PHBs of provider T meeting that meet the requirements of
   Diffserv Intercon Assured Elastic Treatment Aggregate requirements is AF2. are AF2x.
   Hence AF31 traffic received at the interconnection with provider T is
   remarked to AF21 by the peering router of domain T.  As T, and domain T deploys MPLS, further
   the has
   chosen to use MPLS TC ist set to 2. value 2 for this aggregate.  Traffic received
   with AF32 is similarly remarked to
   AF22.  The AF22, but uses the same MPLS TC of
   for the Treatment Aggregate is the same, Aggregate, i.e. TC 2.  At the pen-ultimate penultimate MPLS
   node, the top MPLS label is removed.  The packet should be forwarded
   as determined by the incoming MPLS TC.  The peering router connecting
   domain T with domain F classifies the packet by it's domain T
   internal DSCP AF21 for the Diffserv Intercon Assured Elastic
   Treatment Aggregate.  As it leaves domain T on the interface to
   domain F, it is this causes the packet to be remarked to AF31.  The peering
   router of domain F classifies the packet for domain F internal PHB
   CS4, as this is the PHB with properties matching DiffServ Intercon's
   Assured Elastic Treatment Aggregate.  Likewise, AF21 traffic is
   remarked to AF32 by the peering router od domain T when leaving it
   and from AF32 to CS3 by domain F's peering router when receiving it.

   This example can be extended.  Suppose Provider-O also supports a PHB
   marked by CS2 and this PHB is supposed to be transported by QoS
   within Provider-T domain.  Then Provider-O will remark it with a DSCP
   other than the AF31 DSCP in order to preserve the differentiation distinction from
   CS2; AF11 is one possibility that might be private to the
   interconnection between Provider-O and Provider-T; there's no
   assumption that Provider-W can also use AF11, as it may not be in the
   SLA with Provider-W.

   Now suppose Provider-W supports CS2 for internal use only.  Then no
   DiffServ intercon Intercon DSCP mapping may be configured at the peering
   router.  Traffic, sent by Provider-W to Provider-T marked by CS2 due
   to a misconfiguration may be remarked to CS0 by Provider-T.

   See section 3.1 4.1 for further discussion of this and DSCP transparency
   in general.

   RFC5127 specifies a separate Treatment Aggregate for network control
   traffic.  It may be present at interconnection interfaces too, but
   depending on the agreement between providers, Network Control traffic
   may also be classified into a different interconnection class.  See
   section 3.2 for a detailed discussion on the treatment of Network
   Control traffic.

   RFC2575 states that Ingress nodes must condition all other inbound
   traffic to ensure that the DS codepoints are acceptable; packets
   found to have unacceptable codepoints must either be discarded or
   must have their DS codepoints modified to acceptable values before
   being forwarded.  For example, an ingress node receiving traffic from
   a domain with which no enhanced service agreement exists may reset
   the DS codepoint to the Default PHB codepoint.  As a consequence, an
   interconnect SLA needs to specify not only the treatment of traffic
   that arrives with a supported interconnect DSCP, but also the
   treatment of traffic that arrives with unsupported or unexpected
   DSCPs.

   The proposed interconnect class and code point scheme is designed for
   point to point IP layer interconnections among MPLS networks.  Other
   types of interconnections are out of scope of this document.  The
   basic class and code point scheme is applicable on Ethernet layer
   too, if a provider e.g. supports Ethernet pririties priorities like specified
   by IEEE 802.1p.

3.1.

4.1.  End-to-end QoS: PHB and DS CodePoint Transparency

   This section describes how the use of a common PHB and DSCP scheme
   for interconnection can lead to end-to-end DiffServ-based QoS across
   networks that do not have common policies or practices for PHB and
   DSCP usage.  This will initially be possible for PHBs and DSCPs
   corresponding to at most 3 or 4 Treatment Aggregates due to the MPLS
   considerations discussed previously.

   Networks can be expected to differ in the number of PHBs available at
   interconnections (for terminating or transit service) and the DSCP
   values used within their domain.  At an interconnection, Treatment
   Aggregate and PHB properties are best described by SLAs and related
   explanatory material.  See annex A for a more detailed discussion
   about why PHB and g DSCP usage is likely to differ among networks.  For the above reasons and the desire to
   support interconnection among networks with different DiffServ
   schemes, the DiffServ interconnection scheme supports a small number
   of PHBs and DSCPs; this scheme is expandable.

   The basic idea is that traffic sent with a DiffServ interconnect PHB
   and DSCP is restored to that PHB and DSCP (or a PHB and DSCP within
   the AF3 PHB group for the Assured Treatment Aggregate) at each
   network interconnection, even though a different PHB and DSCP may be
   used by each network involved.  So, Bulk Inelastic traffic could be
   sent with AF41, remarked to CS3 by the first network and back to AF41
   at the interconnection with the second network, which could mark it
   to CS5 and back to AF41 at the next interconnection, etc.  The result
   is end-to-end QoS treatment consistent with the Bulk Inelastic
   Traffic Aggregate, and that is signaled or requested by the AF41 DSCP
   at each network interconnection in a fashion that allows each network
   operator to use their own internal PHB and DSCP scheme.

   The key requirement is that the network ingress interconnect DSCP be
   restored at network egress, and a key observation is that this is
   only feasible in general for a small number of DSCPs.

3.2.

4.2.  Treatment of Network Control traffic at carrier interconnection
      interfaces

   As specified by RFC4594, section 3.2, Network Control (NC) traffic
   marked by CS6 is to be expected at some interconnection interfaces.
   This document does not change NC specifications of RFC4594, but observes that network
   control traffic received at network ingress is generally different
   from network control traffic within a network that is the primary use
   of CS6 envisioned by RFC 4594.  A specific example is that some CS6
   traffic exchanged across carrier interconnections is terminated at
   the network ingress node (e.g., node, e.g. if BGP is running between two routers
   on opposite ends of an interconnection link),
   which is consistent with RFC 4594's recommendation link;in this case the
   operators would enter into a bilateral agreement to not use CS6
   when forwarding CS6-marked traffic originating from user-controlled
   end points. for that
   BGP traffic.

   The end-to-end QoS discussion in the previous section (3.1) (4.1) is
   generally inapplicable to network control traffic - network control
   traffic is generally intended to control a network, not be
   transported across it.  One exception is that network control traffic
   makes sense for a purchased transit agreement, and preservation of
   the CS6 DSCP marking for network control traffic that is transited is
   reasonable in some cases, although it is generally inappropriate to
   use CS6 for transiting traffic, including transiting network control traffic that is transited is reasonable in
   some cases.
   traffic.  Use of an IP tunnel is suggested in order to reduce the
   risk of CS6 markings on transiting network control traffic being
   interpreted by the network providing the transit.

   If the MPLS Short Pipe model is deployed for non tunneled non-tunneled IPv4
   traffic, an IP network provider should limit access to the CS6 and
   CS7 DSCPs so that they are only used for network control traffic for
   the provider's own network.

   Interconnecting carriers should specify treatment of CS6 marked
   traffic received at a carrier interconnection which is to be
   forwarded beyond the ingress node.  An SLA covering the following
   cases is recommended when a provider wishes to send CS6 marked
   traffic across an interconnection link which isn't terminating at the
   interconnected ingress node:

   o  classification of traffic which is network control traffic for
      both domains.  This traffic should be classified and marked for
      the NC PHB.

   o  classification of traffic which is network control traffic for the
      sending domain only.  This traffic should be classified for a PHB
      offering similar properties as the NC class (e.g.  AF31 as
      specified by this document).  As an example GSMA IR.34 proposes an
      Interactive class / AF31 to carry SIP and DIAMETER traffic.  While
      this is service control traffic of high importance to the
      interconnected Mobile Network Operators, it is certainly no not
      Network Control traffic for a fixed network providing transit.
      The example may transit
      between such operators, and hence should not be perfect.  It was picked nevertheless
      because it refers to an existing standard. receive CS6 treatment
      in such a network.

   o  any other CS6 marked traffic should be remarked or dropped.

4.

5.  Acknowledgements

   Al Morton and Sebastien Jobert provided feedback on many aspects
   during private discussions.  Mohamed Boucadair and Thomas Knoll
   helped adding awareness of related work.  Fred Baker and Brian
   Carpenter provided intensive feedback and discussion.

5.

6.  IANA Considerations

   This memo includes no request to IANA.

6.

7.  Security Considerations

   This document does not introduce new features, it describes how to
   use existing ones.  The security section considerations of RFC 2475 [RFC2475]
   and RFC 4594 [RFC4594] apply.

7.

8.  References

7.1.

8.1.  Normative References

   [RFC2119]  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]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
              "Assured Forwarding PHB Group", RFC 2597, June 1999.

   [RFC3246]  Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
              J., Courtney, W., Davari, S., Firoiu, V., and D.
              Stiliadis, "An Expedited Forwarding PHB (Per-Hop
              Behavior)", RFC 3246, March 2002.

   [RFC3260]  Grossman, D., "New Terminology and Clarifications for
              Diffserv", RFC 3260, April 2002.

   [RFC3270]  Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
              P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
              Protocol Label Switching (MPLS) Support of Differentiated
              Services", RFC 3270, May 2002.

   [RFC5129]  Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
              Marking in MPLS", RFC 5129, January 2008.

   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
              Class" Field", RFC 5462, February 2009.

   [RFC5865]  Baker, F., Polk, J., and M. Dolly, "A Differentiated
              Services Code Point (DSCP) for Capacity-Admitted Traffic",
              RFC 5865, May 2010.

   [min_ref]  authSurName, authInitials., "Minimal Reference", 2006.

7.2.

8.2.  Informative References

   [I-D.knoll-idr-cos-interconnect]
              Knoll, T., "BGP Class of Service Interconnection", draft-
              knoll-idr-cos-interconnect-13 (work in progress), November
              2014.

   [ID.idr-sla]
              IETF, "Inter-domain SLA Exchange", IETF,
              http://datatracker.ietf.org/doc/
              draft-ietf-idr-sla-exchange/, 2013.

   [IEEE802.1Q]
              IEEE, "IEEE Standard for Local and Metropolitan Area
              Networks - Virtual Bridged Local Area Networks", 2005.

   [IR.34]    GSMA Association, "IR.34 Inter-Service Provider IP
              Backbone Guidelines Version 7.0", GSMA, GSMA IR.34
              http://www.gsma.com/newsroom/wp-content/uploads/2012/03/
              ir.34.pdf, 2012.

   [MEF23.1]  MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet
              Class of Service Phase 2", MEF, MEF23.1
              http://metroethernetforum.org/PDF_Documents/technical-
              specifications/MEF_23.1.pdf, 2012.

   [RFC2983]  Black, D., "Differentiated Services and Tunnels", RFC
              2983, October 2000.

   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4594, August
              2006.

   [RFC5127]  Chan, K., Babiarz, J., and F. Baker, "Aggregation of
              Diffserv Service Classes", RFC 5127, February 2008.

   [RFC5160]  Levis, P. and M. Boucadair, "Considerations of Provider-
              to-Provider Agreements for Internet-Scale Quality of
              Service (QoS)", RFC 5160, March 2008.

   [Y.1566]   ITU-T, "Quality of service mapping and interconnection
              between Ethernet, IP and multiprotocol label switching
              networks", ITU,
              http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012.

Appendix A.  Annex  Appendix A Carrier interconnection related DiffServ aspects

   NOTE: This Appendix is likely to be deleted in the next version of
   this draft.  The authors would appreciate comments on the value (or
   lack thereof) of this text.

   This annex apppendix provides a general discussion of PHB and DSCP mapping
   at IP interconnection interfaces.  It also informs about limitations and
   likely DSCP changes.

   The following scenarios start from a domain sending non-tunneled IP
   traffic using a PHB and a corresponding DSCP to an interconnected
   domain.  The receiving domain may may:

   o  Support the PHB and offer the same corresponding DSCP.

   o  Not support the PHB and use the DSCP for a different PHB.

   o  Not support the PHB and not use the DSCP.

   o  Support the PHB with a differing DSCP, and the DSCP of the sending
      domain is not used for another PHB

   o  Support the PHB with a differing DSCP, and the DSCP of the sending
      domain is used for another PHB.

   RFC2475 allows for local use PHB groups PHBs which are only available within a
   domain.  If any such a local use PHB is present, non-tunneled IP
   traffic possibly cannot utilize 64 DSCPs end-to-end.

   If a domain receives traffic for a PHB, which it does not support,
   there are two general scenarios:

   o  The received DSCP is not available for usage within the domain.

   o  The received DSCP is available for usage within the domain.

   RFC2474 suggests to transport transporting packets received with unrecognized
   DSCPs by the default Default PHB and leave not changing the DSCP as received.  Also
   if a particular DSCP is spare unused within a domain, it the network may later
   subsequently change its QoS design and assign a PHB to a formerly
   unused DSCP (which a customer
   used to transit through this unrecognized DSCP will note, as his DSCP
   will the be remarked).  A DSCP, making transparent transport of the same that DSCP as an unknown
   DSCP with the default Default PHB may no longer be possible.  Remarking to another
   DSCP apart from the Default PHBs DSCP does not seem to be a good
   option in the latter case.  Which case, as it's not clear which other DSCP is making sense? should
   be used.  If a domain interconnects with many other domains, the questions
   asked
   concerns discussed here may have to be answered multiple dealt with many times.

   The scenarios above indicate, that reliably delivering a non-tunneled
   IP packet by the same PHB and DSCP unchanged end-to-end is only
   likely, if both domains support this DSCP and use the same
   corresponding DSCP.

   Limitations in the number of supported PHBs are to be expected if
   DiffServ is applied across different domains.  Unchanged end-to-end
   DSCPs should only be expected for non-tunneled IP traffic, if the PHB
   and DSCP are well specified and generally deployed.  This is true for
   Default Forwarding.  EF PHB is a candidate.  The Network Control PHB
   is a local use only example, hence end-to-end support of CS6 for non-
   tunneled IP traffic at interconnection points should only be
   expected, if the receiving domain regards this traffic as Network
   Control traffic relevant for the own domain too.

   DiffServ Intercon proposes a well defined set of PHBs and corresponding DSCPs at
   interconnection points.  A PHB to DSCPs correspondence is specified at least
   for interconnection interfaces.  Supported PHBs should be available
   end-to-end, but domain internal DSCPs may change end-to-end. end-to-end, although
   they are restored at network interconnection points.

Appendix B.  Annex 2  Appendix B The MPLS Short Pipe Model and IP traffic

   The MPLS Short Pipe Model (or Pen-ultimate penultimate Hop Label Popping) is
   widely deployed by IP carriers. in carrier networks.  If non-tunneled IPv4 traffic is
   transported using MPLS Short Pipe, IP headers appear inside the last
   section of the MPLS domain.  This likely impacts the number of PHBs and
   DSCPs that a network provider supports for this kind of traffic. can reasonably support . See Figure 2 provides an example
   (below) for the treatment of this kind of
   traffic.

   In the case of an example.

   For tunneled IPv4 traffic, only the outer tunnel header is
   exposed.  Assuming involved
   in forwarding.  If the tunnel does not to terminate within the MPLS
   network section, only the outer tunnel DSCP is impacted. involved, as the inner
   DSCP does not affect forwarding behavior.

   Non-tunneled IPv6 traffic and as well as Layer 2 and Layer 3 VPN traffic
   all use an additional label.  Hence no IP header is exposed MPLS label; forwarding within an MPLS
   domain. network
   is based on that label, as opposed to the outer IP header.

   Carriers may first design their own often select QoS PHB PHBs and codepoint scheme
   before they worry about DSCP without regard to
   interconnection.  PHB  As a result PHBs and corresponding
   codepoint schemes usually DSCPs typically differ between different
   network carriers.  PHBs may be mapped.  A  With the exception of best
   effort traffic, a DSCP rewrite change should be expected at an
   interconnection interface at least for plain IP traffic.

   RFC3270 suggests deployment of traffic even if the PHB is
   mapped across the carriers involved.

   Beyond RFC3270's suggestions that the Short Pipe Model is only in the case
   of VPNs.  State of the art deployments
   applicable to VPNs, current network structures also support use it to
   transport of non tunneled IPv4 traffic.  This is shown in figure 2.

                |
       \|/           IPv4, DSCP_send
        V
        |
   Peering Router
        |
       \|/           IPv4, DSCP_send
        V
        |
   MPLS Edge Router
        |          Mark MPLS Label, TC_internal
       \|/         Remark DSCP to
        V            (Inner: IPv4, DSCP_d)
        |
   MPLS Core Router  (pen-ultimate  (penultimate hop label popping)
        |                        \
        |            IPv4, DSCP_d |  The DSCP needs to be in domain network-
        |                 ^^^^^^^^|  internal QoS context. The Core
       \|/                         > Router might require or enforce
        V                         |  it. The Edge Router may wrongly
        |                         |  classify, if the DSCP is not in
        |                        /   domain internal   network-internal DiffServ context.
   MPLS Edge Router
        |                        \   With well defined PHBs and   Traffic leaves the network marked
       \|/           IPv4, DSCP_d |  corresponding DSCPs at interdomain  with the network-internal
        V                          > links, more than one DSCP per DSCP_d that must be dealt with
        |                         |  treatment aggregate may pass a  by the next network (downstream).
        |                        /   domain and carry a well defined
   Peer Router                       DSCP when leaving it.
        |          Remark DSCP to
       \|/           IPv4, DSCP_send
        V
        |

   Short-Pipe / Pen-ultimate penultimate hop popping example

                                 Figure 2

   The packets IP DSCP must be in a well understood Diffserv context for
   schedulers and classifiers on the interfaces of the ultimate MPLS
   link.  These are domain internal
   link (last link traversed before leaving the network).  The necessary
   Diffserv context is network-internal and a domain network operating in this
   mode enforces DSCPs resulting DSCP usage in reliable domain internal order to obtain robust QoS operation. behavior.

   Without DiffServ-Intercon treatment, the traffic always leaves the
   domain having internal DS codepoints. is likely to leave
   each network marked with network-internal DSCP.  DSCP_send of the
   figure above is remarked to the receiving domains network's DiffServ scheme.

   It leaves the domain marked by the domains DSCP_d.  Every  This structure
   requires that every carrier must deploy per
   peer deploys per-peer PHB and DSCP mapping
   schemes.

   If DiffServ-Intercon is applied, only applied DSCPs for traffic terminating within a
   domain must be aligned with the domain internal DiffServ Codepoint
   scheme.  Traffic transiting through the
   domain can be easily mapped from and remapped to an original DSCP.  This is
   shown in figure 3.  Of
   course the domain  Internal traffic may continue to use internal limitations caused by the Short Pipe model
   still apply.
   DSCPs (e.g, DSCP_d) and those may also be used between a carrier and
   its direct customers.

   Internal Router
        |
        |   Outer Header
       \|/    IPv4, DSCP_send
        V
        |
   Peering Router
        |  Remark DSCP to
       \|/    IPv4, DSCP_ds-int    DiffServ Intercon DSCP and PHB
        V
        |
   MPLS Edge Router
        |
        |   Mark  MPLS Label, TC_internal
       \|/  Remark DSCP to
        V     (Inner: IPv4, DSCP_d)   domain internal DSCP for
        |                             the PHB
   MPLS Core Router  (pen-ultimate  (penultimate hop label popping)
        |
        |     IPv4, DSCP_d
        |           ^^^^^^
       \|/
        V
        |
        |
   MPLS Edge Router--------------------+
        |                              |
       \|/  Remark DSCP to            \|/  IPv4, DSCP_d
        V     IPv4, DSCP_ds-int        V
        |                              |
        |                              |
   Peer Router              Domain internal Broadband
        |                        Access Router
       \|/  Remark DSCP to            \|/
        V     IPv4, DSCP_send          V  IPv4, DSCP_d
        |                              |

   Short-Pipe example with Diffserv-Intercon

                                 Figure 3

   Picking up terminology of RFC2983 and RFC3270, DiffServ intercon
   emulates the long pipe model for the PHBs it supports, if traffic is
   terminating in the receiving domain.

   Looking at the peering interfaces only, for transiting QoS traffic
   DiffServ-Intercon emulates the uniform model for the PHBs and DSCPs
   supported.  Packets are expected to leave a domain with the DSCP/PHB
   as received (and per flow within each PHB in the same order as
   received).  MPLS Treatment Aggregates should not experience
   congestion under standard operational conditions.  The peering links
   need to engineered to be congestion free too for QoS PHBs, if also
   the IP transit transport is to be congestion free.

Appendix C.  Change log

   00 to 01  Added terminology and references.  Added details and
           information to interconnection class and codepoint scheme.
           Editorial changes.

   01 to 02  Added some references regarding related work.  Clarified
           class definitions.  Further editorial improvements.

   02 to 03  Consistent terminology.  Discussion of Network Management
           PHB at interconnection interfaces.  Editorial review.

   03 to 04  Again improved terminology.  Better wording of Network
           Control PHB at interconnection interfaces.

   04 to 05  Large rewrite and re-ordering of contents.

   05 to 06  Description of IP and MPLS related requirements and
           constraints on DSCP rewrites.

   06 to 07  Largely rewrite, improved match and comparison with RFCs
           4594 and 5127.

   07 to 08  Added Annex A and B which where forgotten when putting
           together -07

Authors' Addresses

   Ruediger Geib (editor)
   Deutsche Telekom
   Heinrich Hertz Str. 3-7
   Darmstadt  64295
   Germany

   Phone: +49 6151 5812747
   Email: Ruediger.Geib@telekom.de

   David L. Black
   EMC Corporation
   176 South Street
   Hopkinton, MA
   USA

   Phone: +1 (508) 293-7953
   Email: david.black@emc.com