TSVWG                                                       R. Geib, Ed.
Internet-Draft                                          Deutsche Telekom
Intended status: Informational                              July 4, 2014                                  D. Black
Expires: January 5, April 27, 2015                                  EMC Corporation
                                                        October 24, 2014

             DiffServ interconnection classes and practice
                 draft-geib-tsvwg-diffserv-intercon-06
                 draft-geib-tsvwg-diffserv-intercon-07

Abstract

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

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 January 5, April 27, 2015.

Copyright Notice

   Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Related work . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . .  MPLS and the Short Pipe tunnel model . . . . . . . . . . . . .  5
   3.  An Interconnection class and codepoint scheme  . . . . . . . .  5  6
     3.1.  Limitations arising from the MPLS Short Pipe model  End-to-end QoS: PHB and DS CodePoint Transparency  . . . .  9 11
     3.2.  Treatment of Network Control traffic at carrier
           interconnection interfaces . . . . . . . . . . . . . . . .  9
   4.  DiffServ Intercon relation to other QoS standards
       (revision may be required) . . . . . . . . . . . . . . . . . . 10
     4.1.  MPLS, Ethernet and DSCP Precedence Prefixes for
           aggregated classes . . . . . . . . . . . . . . . . . . . . 11
     4.2.  Proposed GSMA IR.34 to DiffServ Intercon mapping . . . . . 11
     4.3.  Proposed MEF 23.1 to DiffServ Intercon mapping . . . . . . 12
   5.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   7. 13
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8. 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.1.
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     9.2.
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Change log  . . . . . . . . . . . . . . . . . . . . . 16
   Author's Address .
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

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 for consistency with
   default (best effort) forwarding.

   Many providers operate MPLS based backbones.  RFC 5127 assumes MPLS-based backbones that employ backbone
   traffic engineering to ensure that if a major link, switch, or router
   can fail, and
   fails, the result will be a routed network that still meets
   ambient continues to meet its
   Service Level Agreements classes(SLAs) [RFC5127]. (SLAs).  Based on
   it, RFC5127 that foundation,
   foundation, [RFC5127] introduces the concept of DiffServ Treatment
   Aggregates, which
   allow to forward enable traffic marked with multiple DSCPs by to be
   forwarded in a single MPLS Traffic Class.  This
   draft shares the assumption of Class (TC).  Like RFC 5127 on 5127, this
   document assumes robust provider backbone engineering.
   RFC3270 adds the Short Pipe Models to the Pipe and Uniform Model
   already defined for Differentiated Services and Tunnels [RFC2983] ,
   [RFC3270].  It was required due to the presence of Pen-ultimate hop
   popping (PHP) of MPLS Labels.  RFC3270 expects the Short Pipe model
   only to be deployed for IP tunnels and VPNs.  If it used to transport
   non tunneled IP traffic, some restrictions may apply for DSCP
   transparency.  The Short Pipe model is popular with many network
   providers operating MPLS.

   RFC2474 specifies the DiffServ Codepoint Field [RFC2474].
   Differentiated treatment is based on the specific DSCP.  Once set, it
   may change, but any DSCP rewrite is always a one by one mapping.
   What is not allowed is remarking n received DSCPs to a single
   transmitted DSCP.  If unknown DSCPs are received, RFC2474 recommends
   transmitting them unchanged by default forwarding.  An MPLS network
   supporting the Short Pipe model for not tunneled IPv4 traffic may
   need to be able to correctly classify or rewrite the IP DSCP on
   interfaces between the last Label Switch Router and a Label Edge
   Router.  In that case, it may not be possible to transmit 64 DSCPs
   through this domain. engineering.

   RFC5127 proposes to transmit recommends transmission of DSCPs as they are received in general. received.  This
   is not possible, if the receiving and the transmitting domain domains at a
   network interconnection use different DSCPs for the PHBs to which traffic is mapped if both
   interconnect. involved.

   This draft adresses document is motivated by requirements for IP network
   interconnection supporting with DiffServ to or
   between support among providers operating that operate
   MPLS in their backbone.  It proposes backbones, but is applicable to other technologies.
   The operational simplifications and methods to match in this document help
   align IP DiffServ
   requirements functionality with MPLS limitations (especially regarding the Short
   Pipe Model if applied for non tunnel IPv4 traffic).  The scope of
   this draft limitations, particularly
   when MPLS penultimate hop popping is limited to used.  That is an important
   reason why this document specifies 4 specified interconnection Treatment
   Aggregates.  To ease operation and  Limiting DiffServ to a small number Treatment Aggregates
   can help ensure that network traffic to leave leaves a
   domain network with the same
   DSCPs received, small sets of specific DSCPs and a
   definition of their Treatment Aggregate PHB are suggested. that it was received with.  The
   mechanism approach proposed here may be extended.  This is relevant only if it
   sees some deployment, and it is preferred to start with a limited and
   simple approach to clarify the concept.

   At first glance, the
   extended by operators or future specifications.

   In isolation, use of standard interconnection codepoint scheme PHBs and DSCPs may look like
   an additional effort.  But there are some obvious benefits: each
   party sending or receiving traffic has
   appear to specify be additional effort for a network operator.  The primary
   offsetting benefit is that the mapping from or to the interconnection class
   PHBs and code point scheme only once.
   Without it, this 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 per interconnection party
   individually. and configured independently for each
   network interconnection, which has poor scaling properties.  Further,
   end-to-end QoS in terms of traffic being
   classified for say, for a sufficiently similar PHB in all passed
   domains treatment is more likely to result if when an
   interconnection code point scheme is used. used because traffic is remarked
   to the same PHBs at all network interconnections.  This draft document
   supports a remarking of one one-to-one DSCP only to
   one other DSCPs (no remarking at network interconnections (not n
   DSCP to one DSCP remarking).

   The example given in RFC 5127 on aggregation of DiffServ service
   classes picks 4 Treatment Aggregates.  This draft also favours 4
   Treatment Aggregates.  Reasons to favour working with uses 4 DiffServ Treatment Aggregates:

   o  There should be a coding reserve for interconnection classes.
      This leaves space for future standards, for private bilateral
      agreements Aggregates, and for provider internal classes. this document does likewise
   because:

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

   o  Migrations from one code point scheme to another may require spare
      QoS code points.  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.

   RFC5127 provides recommendations on aggregation of IP DSCPs DSCP-marked
   traffic into MPLS Treatment Aggregates and offers a deployment
   example [RFC5127].
   RFC5127 seems to be based on an assumption the [RFC5127] that does not work for the MPLS Short Pipe model
   when that model is only deployed used for tunneled IP products or VPNs. ordinary network traffic.  This draft
   assumes presence of non tunneled IPv4 traffic and deployment of document
   supports the MPLS Short Pipe model.  That requires deviating model for ordinary network traffic and
   hence differs from the RFC5127
   example approach as follows:

   o  DSCP  remarking of received DSCPs to domain internal DSCPs is to be
      expected for ordinary IP traffic at provider edges, if the domain
      is terminating this traffic. edges (and for outer
      headers of tunneled IP traffic).

   o  This draft  document follows RFC4594 in the proposed marking of provider
      Network Control traffic and expands RFC4594 on treatment of CS6
      marked traffic at interconnection points (see section 5.2).

   The proposed Interconnection class 3.2).

   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
   introduces DiffServ interconnection Treatment Aggregates, plus the
   PHBs and code point scheme tries DSCPs that are mapped to
   reflect these Treatment Aggregates.
   Further, section 3 discusses treatment of non-tunneled and consolidate related DiffServ tunneled
   IP traffic and MPLS VPN QoS standardisation
   efforts outside of the IETF, namely MEF [MEF 23.1], GSMA [IR.34] and
   ITU [Y.1566].  GSMAs IR.34 specifies an inter provider VPN, but it aspects.  Finally Network Management PHB
   treatment is
   nevertheless specifying a kind of DiffServ aware described.  Annex A discusses how domain internal IP based carrier
   layer QoS schemes impact interconnection.  Annex B describes the
   impact of the MPLS Short Pipe model (pen ultimate hop popping) on QoS
   related IP interconnections.

1.1.  Related work

   In addition to the standardisation activities which that triggered this work, other authors published there are
   additional RFCs or drafts which and Internet-drafts that may benefit from an
   interconnection class- PHB and codepoint DSCP scheme.  RFC 5160 suggests Meta-QoS-
   Classes to enable deployment of standardised standardized end to end QoS classes
   [RFC5160].  The  In private discussion, the authors of that RFC agree that
   the proposed interconnection class- and codepoint scheme as well as the idea 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.  Should  When the basic transport and class properties
   be standardised as proposed here, DiffServ elements for network
   interconnection are used as described in this document, signaled
   access to QoS classes may be of interest.  The current  These two BGP drafts documents
   focus on exchanging SLA and traffic conditioning parameters.  They seem to parameters and
   assume that common
   interpretation of the PHB properties PHBs identified by the signaled DSCPs has have been
   established prior to exchanging further details by BGP signaling.

2.  Terminology

   This draft reuses existing terminology signaling of RFCs 2474 and 5127.

3.  An Interconnection class QoS.

2.  MPLS and codepoint scheme

   Interconnecting parties face the problem of matching classes to be
   interconnected Short Pipe tunnel model

   The Pipe and then to agree on code point mapping.  As stated by
   the DiffServ Architecture [RFC2475], remarking is a standard
   behaviour at interconnection interfaces.  If Uniform models for Differentiated Services and Tunnels
   are defined in [RFC2983].  RFC3270 adds the MPLS Short Pipe model is deployed by the receiving domain, the Label Switch Router
   prior in
   order to support penultimate hop popping (PHP) of MPLS Labels,
   primarily for IP tunnels and the destination Label Edge Router may VPNs.  The Short Pipe model and PHP have to correctly
   classify
   become popular with many network providers that operate MPLS networks
   and are now widely used for ordinary network traffic, not just
   traffic by its DSCP.  To avoid DSCPs being misused, only
   domain internal DSCPs may be tolerated there. encapsulated in IP tunnels and VPNs.  This means, that has important
   implications for DiffServ functionality in MPLS networks.

   RFC 2474's recommendation to forward traffic terminating within this domain will be delivered with unrecognized DSCPs
   with Default (best effort) service without rewriting the DSCP matching has
   proven to be a poor operational practice.  Network operation and
   management are simplified when there is a 1-1 match between the properties of DSCP
   marked on the PHB at interconnection, but with packet and the DSCP assigned forwarding treatment (PHB) applied by
   network nodes.  When this is done, CS0 (the all-zero DSCP) is the terminating domain.  This draft proposes a
   standard interconnection set
   only DSCP used for Default forwarding of 4 Treatment Aggregates best effort traffic, so a
   common practice is to use CS0 to remark traffic received with well
   defined
   unrecognized or unsupported DSCPs at network edges.

   MPLS networks are more subtle in this regard, as it is possible to be aggregated by them.  A sending party remarks
   DSCPs from internal schemes to
   encode the Interconnection code points.  The
   receiving party remarks DSCPs provider's DSCP in the MPLS TC field and allow that to her internal scheme.  The
   interconnection code point scheme fully complies with
   differ from the DiffServ
   architecture.  DiffServ compliance does not PHB indicated by the DSCP in the MPLS-encapsulated IP
   packet.  That would allow for a rewrite of
   several received DSCPs with a single an unrecognized DSCP to be transmitted.  The set
   of DSCPs and PHBs supported accross the two interconnected domains
   and carried edge-to-
   edge over an MPLS network, because the treatment of PHBs and DSCPs not recognised effective DSCP used by any of both
   domains should be part of an SLA.  DiffServ transit to a third party the
   MPLS network is excluded for initial versions of this draft (but may would be
   added if there's interest).

   This draft picks up encoded in the DiffServ interconnection class defintions
   proposed by ITU-T Y.1566 [Y.1566].  The classes defined there, are
   used as MPLS Treatment Aggregates here.  This draft proposes label TC field (and also
   carried edge-to-edge); this approach assumes that a set of
   Treatment Aggregate PHBs and DSCPs to be aggregated.  Their
   properties differ slightly from those of provider MPLS
   label with the RFC5127 example:

   Class Priority:  PHB EF, DSCP 101 110. provider's TC field being present at all hops within
   the provider's network.

   The figures 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 merit
           describing the PHB to be MPLS tunnel
   endpoint, resulting in no provider TC info being available at tunnel
   egress.  Therefore the DSCP field in the range of low single digit
           milliseconds.  See [RFC3246].  This class corresponds MPLS-encapsulated IP header
   has to RFC
           5127's real time class, but it contain a DSCP that is limited to traffic valid for
           which node configuration "ensures that the service rate provider's network;
   propagating another DSCP edge-to-edge requires an IP tunnel of EF
           packets on a given output interface exceeds their arrival
           rate at that interface over long and short time intervals"
           (see RFC 3246).

   Bulk inelastic:  The Treatment Aggregate some
   form.  In the absence of IP tunneling (a common case for MPLS
   networks), it is initially designed only not possible to transport PHB AF41, pass all 64 possible DSCP 100 010 (the other AF4 PHB group
           PHB's and DSCPs should be reserved values
   edge-to-edge across an MPLS network.  See Annex B for future extension of
           the set a more detailed
   discussion.

   If transport of a large number (much greater than 4) DSCPs carried by is
   required across a network that supports this Treatment Aggregate).
           Optimised DiffServ interconnection
   scheme, a tunnel or VPN can be provisioned for low loss, low delay, low jitter at high
           bandwidth.  Traffic load in this class must be controlled,
           e.g. by application servers.  One example could be flow
           admission control.  There may be infrequent retransmissions
           requested by purpose, so that
   the application layer inner IP header carries the DSCP that is to mitigate low levels of
           packet losses.  Discard of packets through active queue
           management should be avoided in this class.  Congestion in
           this class may result in bursty packet loss.  If used preserved not to
           carry multimedia traffic, it
   be changed.  From a network operations perspective, the customer
   equipment (CE) is recommended to carry audio
           and video traffic in the preferred location for tunnel termination,
   although a single PHB (note that video
           conferencing may require separate receiving domains Provider Edge router is another viable
   option.

3.  An Interconnection class and codepoint scheme

   At an interconnection, the networks involved need to agree on the
   PHBs used for audio interconnection and video
           traffic, which could also be realised by utilising two AF 4
           PHBs).  All of these properties influence the buffer design. specific DSCP for each PHB.
   This class may involve remarking for the interconnection; such remarking is designed to transport those parts
   part of RFC 5127's
           Real Time class, which consume considerable QoS bandwidth 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 interface.

   Assured:  The complete PHB group AF3,
   set of 4 Treatment Aggregates with well-defined DSCPs 011 010, 011 100 and 011
           110 is transmitted to be
   aggregated by this Treatment Aggregate.  It may be
           optimised them.  A sending party remarks DSCPs from internal
   schemes to transport traffic without bandwidth
           requirements.  It aims on very low loss at high bandwidths.
           Retransmissions after losses characterise the class and
           influence the buffer design.  Active queue management with
           probabilistic dropping may be deployed.  The RFC 5127 example
           calls this class Assured Elastic.

   Default: interconnection code points.  The Treatment Aggregate for the default PHB, CS0 with DSCP
           000 000.  This class may be optimised receiving party
   remarks DSCPs to transport traffic
           without bandwidth requirements.  Retransmissions after losses
           characterise her internal scheme.  The set of DSCPs and PHBs
   supported across the class two interconnected domains and influence the buffer design.
           Active queue management with probabilistic dropping may be
           deployed.  The RFC 5127 example calls this class Elastic.

   RFC2474 recommends leaving treatment of
   PHBs and DSCPs unknown to a not recognized by the receiving domain
   unchanged while default PHB transport is provided.  If there's
   community interest in this draft, current carrier deployments should be checked for support part
   of this RFC2474 recommendation.

   The idea the interconnect SLA.

   RFC 5127's four treatment aggregates include a Network Control
   aggregate for routing protocols and OAM traffic that is illustrated by an example.  Provider O essential for
   network operation administration, control and provider W are
   peer with provider T. They have agreed upon a QoS interconnection.
   Traffic management.  Using this
   aggregate as one of provider O terminates within provider Ts network, while the GSMA IR.34 four in RFC 5127 implicitly assumes that
   network control traffic transits through the netwirk of provider T to
   provider F. Assume all providers to run their own internal codepoint
   schemes for a class is forwarded in potential competition with properties
   all other network traffic, and hence DiffServ must favor such traffic
   (e.g., via use of the DiffServ Intercon Assured
   Treatment Aggregate.  See below CS6 codepoint) for network stability.  That is
   a description reasonable assumption for IP-based networks where routing and OAM
   protocols are mixed with all other types of GSMA IR.34.

           Provider-O             Provider-W
           RFC5127                GSMA 34.1
               |                      |
          +----------+           +----------+
          |AF21, AF22|           |AF31, AF21|
          +----------+           +----------+
               | 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 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 the approach 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.

   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 proposed queuing mechanism.  The
           latter is however in line with RFC4594.

   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, the Bulk Real-Time Treatment
   Aggregate or the Bulk Real-Time Treatment Aggregate may be a
   reasonable match.

   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 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. |
          | AF21, AF22|
          +-----------+
             |      |  Local DSCPs Provider-T
             |      |  +----------+   +++++++++
             V      +->|AF21, AF22|->-|RtrDstH|
             |         +----------+   +++++++++
         +----------+                 RtrDst:
         |AF21, AF22|                 Router Destination
         +----------+
             |
          +++++++++
          |RtrPrTE|
          +++++++++
             |        DiffServ
         +----------+
         |AF31, AF32|
         +----------+
             |        Intercon

          +++++++++
          |RtrPrHF|
          |RtrPrF|
          +++++++++
             |
         +----------+
         |AF31, AF21|
         | CS4, CS3 |
         +----------+
             |
         Provider-F
         GSM IR.34

   DiffServ Intercon example

                                 Figure 1

   It is easily visible that all providers only need to deploy internal
   DSCP to DiffServ Intercon DSCP mappings to exchange traffic in the
   desired classes.

   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 for another interconnection class.  See below
   for a detailed discussion on the treatment of Network Control
   traffic.

   The proposed class and code point scheme is designed for point to
   point IP layer interconnections.  Other types of interconnections are
   out of scope of this document.  The basic class and code point scheme
   is applicable on Ethernet layer too.

3.1.  Limitations arising from the MPLS Short Pipe model

   If non tunneled IPv4 traffic is transmitted by deploying the MPLS
   Short Pipe model as specified by RFC3270, then IP DSCPs may be used
   for classification or they may be remarked at interfaces between the
   destination Label Edge Router and the Label Switch Router.  Domain
   internal Treatment Aggregates may be applicable, e.g. for domain
   internal network control traffic.  This Treatment Aggregate and the
   DSCPs which are aggregated by it, may not be available for customer
   traffic.  A domain supporting such an internal Treatment Aggregate
   can't support a set of 64 DSCPs in the
   desired classes.  Provider W has decided that case.  As mentioned below, the number properties of his
   internal classes CS3 and CS2 are best met by the Diffserv Intercon
   Assured Elastic Treatment Aggregate, PHBs AF31 and their DSCPs supported end-to-end should be as
   well defined as AF32 respectively.
   At the treatment of not recognised DSCPs when
   negotiating interconnection.

   The situation is more relaxed for tunneled IPv4 traffic, IPv6 outgoing peering interface connecting provider W with provider
   T remarks CS3 traffic
   in general (for the time being) to AF31 and for VPN traffic.  If there's
   community interest, a later version of this discuss this in more
   detail.

3.2.  Treatment of Network Control traffic at carrier interconnection
      interfaces

   As specified by RFC4594, section 3.2, Network Control (NC) CS 2 traffic
   marked by CS6 is to be expected at interconnection interfaces.  This
   document does not change NC specifications of RFC4594. CS32.  The latter
   specification is detailed on domain
   internal NC traffic and on PHBs of provider T meeting the Diffserv Intercon Assured
   Elastic Treatment Aggregate requirements is AF2.  Hence AF31 traffic exchanged between peering points.  Further, it recommends not
   received at the interconnection with provider T is remarked to forward CS6 marked traffic originating from user-controlled end
   points AF21
   by the NC class peering router of a provider domain. domain T. As a minor clarification domain T deploys MPLS, further
   the MPLS TC ist set to RFC4594, "peering" shouldn't be
   interpreted in a commercial sense. 2.  Traffic received with AF32 is remarked to
   AF22.  The NC PHB MPLS TC of the Treatment Aggregate is applicable also in the case of a purchased network service based on a transit agreement
   with an upstream provider.  RFC4594 recommendations on NC traffic are
   applicable for IP carrier interconnections in general.

   Some CS6 traffic exchanged accross carrier interconnections will
   terminate at same, TC 2.  At
   the pen-ultimate 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 ingress node (e.g., if BGP is running between T internal DSCP AF21 for the two routers Diffserv Intercon
   Assured Elastic Treatment Aggregate.  As it leaves domain T on opposite ends of the interconnection link).

   If the MPLS Short Pipe model
   interface to domain F, it is deployed for non tunneled IPv4
   traffic, an IP carrier may limit access remarked to AF31.  The peering router of
   domain F classifies the NC PHB packet for traffic
   which is recognised domain F internal PHB CS4, as network control this
   is the PHB with properties matching DiffServ Intercon's Assured
   Elastic Treatment Aggregate.  Likewise, AF21 traffic relevant is remarked to
   AF32 by the own
   domain.  Interconnecting carriers should specify treatment of CS6
   marked traffic received at 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 carrier interconnection which PHB
   marked by CS2 and this PHB is supposed to be
   forwarded beyond the ingress node.  An SLA covering transported by QoS
   within Provider-T domain.  Then Provider-O will remark it with a DSCP
   other than AF31 DSCP in order to preserve the following
   cases differentiation from
   CS2; AF11 is recommended, if a carrier wishes one possibility that might be private to send CS6 marked traffic
   accross an the
   interconnection link which isn't terminating at between Provider-O and Provider-T; there's no
   assumption that Provider-W can also use AF11, as it may not be in the
   interconnected ingress node:

   o  classification of traffic which is network control traffic
   SLA with Provider-W.

   Now suppose Provider-W supports CS2 for
      both domains.  This traffic should internal use only.  Then no
   DiffServ intercon DSCP mapping may be classified and 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 for
      the NC PHB.

   o  classification further discussion of traffic which is this and DSCP transparency
   in general.

   RFC5127 specifies a separate Treatment Aggregate for network control traffic for
   traffic.  It may be present at interconnection interfaces too, but
   depending on the
      sending domain only.  This agreement between providers, Network Control traffic should
   may also be classified into a different interconnection class.  See
   section 3.2 for a PHB
      offering similar properties as detailed discussion on 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 treatment of high importance to the
      interconnected Mobile Network Operators, it is certainly no Network
   Control traffic for a fixed network providing transit.
      The example may not be perfect.  It was picked nevertheless
      because it refers to an existing standard.

   o  any traffic.

   RFC2575 states that Ingress nodes must condition all other CS6 marked inbound
   traffic should be remarked or dropped.

4.  DiffServ Intercon relation to other QoS standards (revision may ensure that the DS codepoints are acceptable; packets
   found to have unacceptable codepoints must either be
    required)

   This sections provides suggestions how discarded or
   must have their DS codepoints modified to aggregate acceptable values before
   being forwarded.  For example, an ingress node receiving traffic by DSCP
   Precedence Prefexies to Ethernet and MPLS.  Other Standardisation
   Organsiations deal from
   a domain with QoS aware provider interconnection.  As IP is
   the state of which no enhanced service agreement exists may reset
   the art realisation of provider interconnections, these
   standards bodies specify DiffServ aware interconnections.  Some of
   these bodies are industry alliances chartered also DS codepoint to promote
   interconnection of wireless or Ethernet technology including the
   exchange of IP datagrams at interconnection points.  Examples are the
   Metro Ethernet Forum (MEF) or Default PHB codepoint.  As a consequence, an
   interconnect SLA needs to specify not only the GSM Alliance (GSMA).  The ITU was
   mentioned earlier.  ITU works across and between responsibilities treatment of
   different Standardisation Organisations and liaising traffic
   that arrives with them, if
   their responsibilities are touched, is traditional part a supported interconnect DSCP, but also the
   treatment of traffic that
   process.

4.1.  MPLS, Ethernet arrives with unsupported or unexpected
   DSCPs.

   The proposed interconnect class and DSCP Precedence Prefixes code point scheme is designed for aggregated classes
   point to point IP layer interconnections among MPLS networks.  Other
   types of interconnections are out of scope of this document.  The interconnection
   basic class and code point scheme respects properties
   and limits of a 3 bit PHB coding space in different ways:

   o  it allows to classify four interconnection classes based is applicable on the
      DSCP Precedence Prefix.

   o  it supports a single PHB group (AF3), whose DSCPs may be
      aggregated into Ethernet layer
   too, if a sinle MPLS TC (or provider e.g. supports Ethernet priority) based on
      their joint DSCP Precedence Prefix. pririties like specified by
   IEEE 802.1p.

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

   This kind of aggregation will
      work for section describes how the AF4 use of a common PHB group, if the PHBs AF42 and AF43 need to be
      supported in addition to AF41.

   o  Applying only 4 aggregated classes at interconnection allows DSCP scheme
   for
      bilateral extensions, if desired.  Should two carriers agree to
      map AF32 and AF33 interconnection can lead to an additional individual MPLS TC and offer an
      Ordered Aggregate end-to-end DiffServ-based QoS across the interconnecting domain, this proposal
      at leaves some MPLS TC coding space for such an extension
      (although this draft doesn't recommend interconnections of
   networks that
      type).

   The above statement is no requirement to depricate any DSCP to MPLS
   TC do not have common policies or Ethernet P-Bit mapping functionality.  In the opposite, by
   limiting the interconnection scheme to 6 PHBs, each practices for PHB may and
   DSCP usage.  This will initially be mapped possible for PHBs and DSCPs
   corresponding to an individual Traffic Class or Priority also within MPLS at most 3 or
   Ethernet (if desired).

4.2.  Proposed GSMA IR.34 to DiffServ Intercon mapping

   GSMA IR.34 provides guidelines on how to set up and interconnect
   Internet Protocol (IP) Packet eXchange (IPX) Networks [IR.34].  An
   IPX network is an inter-Service Provider IP backbone which comprises
   the interconnected networks of IPX Providers.  IPX is a
   telecommunications interconnection model for 4 Treatment Aggregates due to the exchange of IP based
   traffic between customers MPLS
   considerations discussed previously.

   Networks can be expected to differ in the number of separate mobile PHBs available at
   interconnections (for terminating or transit service) and fixed operators as
   well as other types of service provider (such as ISP), via IP based
   network-to-network interface.  Note that IPX is not a public
   interconnection model however, it is designed as a private IP
   Backbone of the interconnected parties.  Two IPX partners may
   interconnect using transit offered by an Inter-Service Provider IP
   Backbone.  This requires DSCP
   values used within their domain.  At an IP QoS aware interconnection as interconnection, Treatment
   Aggregate and PHB properties are best described by this draft between IPX provider SLAs and Inter-Service Provider IP
   Backbone.

   GSMA IR.34 specifies 4 aggregated classes 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 7 PHBs.  Mapping the desire to support interconnection among
   networks with different DiffServ Intercon is smooth apart from schemes, the GSMA aggregated class
   Interactive, which consistfs DiffServ
   interconnection scheme supports a small number of 4 PHBs. PHBs and DSCPs;
   this scheme is expandable.

   The table below lists basic idea is that traffic sent with a
   suggested mapping to DiffServ Intercon.

   |      GSMA IR.34       |  DiffServ-Intercon    |
   |                       |                       |
   |  Agg. Class   | interconnect PHB  |  Agg. Class  |
   and DSCP is restored to that PHB   |
   +---------------+-------+--------------+--------+
   |Conversational |  EF   |   Priority   |   EF   |
   +---------------+-------+--------------+--------+
   | Streaming     | AF41  |Bulk inelastic|  AF41  |
   +---------------+-------+--------------+--------+
   | Interactive   | AF31  | and DSCP (or a PHB and DSCP within
   the AF3 PHB group for the Assured   |  AF31  |
   +               +-------+              +--------+
   |  (ordered Treatment Aggregate) at each
   network interconnection, even though a different PHB and DSCP may be
   used by  | AF32  |              |        |
   +   priority,   +-------+              +  AF32  +
   | AF3 highest)  | AF21  |              |        |
   +               +-------+              +--------+
   |               | AF11  |              |  AF33  |
   +---------------+-------+--------------+--------+
   | Background    | CS0   |    Default   |   CS0  |
   +---------------+-------+--------------+--------+

   Suggested mapping of GSMA IR.34 classes each network involved.  So, Bulk Inelastic traffic could be
   sent with AF41, remarked to CS3 by the first network and PHBs back to DiffServ Intercon

                                 Figure 2 AF41
   at the interconnection with the second network, which could mark it
   to CS5 and back to AF41 at the next interconnection, etc.  The motivation resulting in result
   is end-to-end QoS treatment consistent with the design of Bulk Inelastic
   Traffic Aggregate, and that is signaled or requested by the IR.34 Intercative class
   are unknown 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 author of network ingress interconnect DSCP be
   restored at network egress, and a key observation is that this draft.  It is out
   only feasible in general for a small number of scope DSCPs.

3.2.  Treatment of this
   draft Network Control traffic at carrier interconnection
      interfaces

   As specified by RFC4594, section 3.2, Network Control (NC) traffic
   marked by CS6 is to decide how 4 PHBs can be mapped to expected at 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 to single aggregated
   class.  The suggested mapping network that is pragmatic and tries to come as close
   as possible to other design criteria pursued the
   primary use of CS6 envisioned by GSMA IR.34.

4.3.  Proposed MEF 23.1 to DiffServ Intercon mapping

   MEF 23.1 RFC 4594.  A specific example is an implemenation agreement facilitating Ethernet service
   interoperability and consistency between Operators and
   that some CS6 traffic exchanged across carrier interconnections is
   terminated at the use network ingress node (e.g., if BGP is running
   between two routers on opposite ends of a
   common CoS Label set for Subscribers [MEF23.1].  It pursues an interconnection link),
   which is consistent with RFC 4594's recommendation to not use CS6
   when forwarding CS6-marked traffic originating from user-controlled
   end points.

   The end-to-end QoS discussion in the same
   aims and method on Ethernet layer as this draft does on IP layer
   (i.e. providing an interconnection class and codepoint scheme).  MEF
   23.1 addresses external network previous section (3.1) is
   generally inapplicable to network interfaces typically
   interconnecting metro ethernet providers.  This may typically involve
   Ethernet Network Sections associated with typical Operator domains
   that interconnect at external control traffic - network control
   traffic is generally intended to control a network, not be
   transported across it.  One exception is that network interfaces.  MEF
   23.1 specifies three aggregated CoS classes.  In addition, the usage
   of control traffic
   makes sense for a subset of Ethernet PCP purchased transit agreement, and IP DSCP values preservation of
   CS6 for network control traffic that is specifiedthus
   facilitating synergies between Ethernet and IP services and networks.

   The main purpose transited is specifying operator virtual (Ethernet)
   connections.  As reasonable in
   some cases.  Use of an IP QoS model tunnel is added, this draft proposes an IP
   class and codepoint mapping.

   MEF 23.1 QoS mapping requires some thought as 3 classes are supported suggested in order to reduce the
   risk of which two are Ordered Aggregates.  MEF 23.1s section 8.5.1 example
   on IP DSCP mapping may suggest supporting classification based CS6 markings on transiting network control traffic being
   interpreted by the
   DSCP Precedence Prefix.  MEF 23.1 section 8.5.2.1 allows network providing the
   conclusion that MEF class M is best mapped to this drafts Bulk
   inelastic class.  The suggested mapping MEF to DiffServ Intercon transit.

   If the MPLS Short Pipe model is
   limited deployed for 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 MEF color blind mode (3 classes, no sub-classes):

   |        MEF 23.1       |  DiffServ-Intercon    |
   |                       |                       |
   |  Agg. Class   |  PHB  |  Agg. Class  |  PHB   |
   +---------------+-------+--------------+--------+
   |    High       |  EF   |   Priority   |   EF   |
   +---------------+-------+--------------+--------+
   |   Medium      | AF3   |Bulk inelastic|  AF41  |
   +---------------+-------+--------------+--------+
   |     Low       | CS1   |    Default   |   CS0  |
   +---------------+-------+--------------+--------+

   Suggested mapping provider's own network.

   Interconnecting carriers should specify treatment of MEF 23.1 color blind mode classes and PHBs CS6 marked
   traffic received at a carrier interconnection which is to
   DiffServ Intercon

                                 Figure 3

   The MEF color aware mode supports Ordered Aggregates in be
   forwarded beyond the MEF
   classes M and L. The MEF L specification classifies AF1 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 Best
   Effort marked for
      the same Ordered Aggregate.  A Better than Best Effort
   service produced in NC PHB.

   o  classification of traffic which is network control traffic for the same queue as best effort
      sending domain only.  This traffic can should be
   realized, but hasn't been standardized by IETF.  This document
   doesn't suggest any mapping.  Diffserv Intercon also doesn't suggest
   an Ordered Aggregate in classified for a PHB
      offering similar properties as the Bulk Inelastic class.  Later versions of NC class (e.g.  AF31 as
      specified by this document may do so document).  As an example GSMA IR.34 proposes an
      Interactive class / AF31 to carry SIP and specify a solution.  Both issues are left DIAMETER traffic.  While
      this is service control traffic of high importance to the
      interconnected Mobile Network Operators, it is certainly no
      Network Control traffic for bilateral negotiation.

5.  Contributors

   David Black provided many helpful comments and inputs a fixed network providing transit.
      The example may not be perfect.  It was picked nevertheless
      because it refers to this work.

6. an existing standard.

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

4.  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.  David Black,  Fred Baker and Brian
   Carpenter provided intensive feedback and discussion.

7.

5.  IANA Considerations

   This memo includes no request to IANA.

8.

6.  Security Considerations

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

9.

7.  References

9.1.

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

9.2.

7.2.  Informative References

   [I-D.knoll-idr-cos-interconnect]
              Knoll, T., "BGP Class of Service Interconnection",
              draft-knoll-idr-cos-interconnect-12 (work in progress),
              May 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.  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.

Author's Address

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

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