TSVWG                                                       R. Geib, Ed.
Internet-Draft                                          Deutsche Telekom
Intended status: Informational                          October 18, 2013                         February 14, 2014
Expires: April 21, August 18, 2014

             DiffServ interconnection classes and practice
                 draft-geib-tsvwg-diffserv-intercon-04
                 draft-geib-tsvwg-diffserv-intercon-05

Abstract

   This document proposes a limited and well defined set of interconnection QoS PHBs and
   PHB groups.  It further introduces some DiffServ deployment aspects.
   The proposals made here should groups to be integrated into a revised version applied at (inter)connections of RFC5127. two separately
   administered and operated networks.  Many network providers operate
   Aggregated DiffServ classes.  This draft contains DiffServ
   aggregation friendly interconnection concepts.

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 April 21, August 18, 2014.

Copyright Notice

   Copyright (c) 2013 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.  Requirements Language  Related work . . . . . . . . . . . . . . . . . .  4 . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4  5
   3.  Aggregating PHBs of a class by a DSCP Precedence Prefix  . . .  5  6
   4.  An Interconnection class and codepoint scheme  . . . . . . . .  6
   5.  Consolidation of QoS standards by the interconnection
       codepoint scheme . . . . . . . . . . . . . . . . . . . . . . .  7
   6.
     4.1.  Treatment of Network Control traffic at carrier
           interconnection interfaces . . . . . . . . . . . . . . . .  9
   5.  DiffServ Intercon relation to other QoS standards  . .  9
   7. . . . . 10
     5.1.  MPLS, Ethernet and DSCP Precedence Prefixes for
           aggregated classes . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Proposed GSMA IR.34 to DiffServ Intercon mapping . . . . . 11
     5.3.  Proposed MEF 23.1 to DiffServ Intercon mapping . . 10
   8.  QoS class name selection . . . . 12
   6.  Contributors . . . . . . . . . . . . . . . 11
   9.  Allow for DiffServ extendibility on MPLS and Ethernet level . 12
   10. . . . . . . . . . 14
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   11. 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   12. 14
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   13. 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     13.1. 14
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     13.2. 14
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13 15
   Appendix A.  Change log  . . . . . . . . . . . . . . . . . . . . . 14 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 16

1.  Introduction

   This draft proposes a DiffServ interconnection class and codepoint
   scheme.  At least one party of an interconnection often is a network
   provider.  Many network providers operate Aggregated DiffServ
   classes.  This draft contains concepts and current practice relevant
   for a revised version of RFC5127 [RFC5127].  Its main purpose is to
   be considered as an input for the latter task.

   DiffServ sees deployment has been deployed in many networks for the time being. networks.  As described in the introduction by section
   2.3.4.2 of the draft DiffServ problem statement
   [I-D.polk-tsvwg-diffserv-stds-problem-statement], RFC 2475, remarking of packets at domain boundaries is a
   DiffServ feature. feature [RFC2475].  This draft proposes a set of standard
   QoS classes and codepoints code points at interconnection points to which and
   from which locally used classes and codepoints code points should be mapped.  Such a scheme simplifies
   interconnection negotiations

   IP precedence has been deprecated.  MPLS and ensures that end Ethernet support 3 bit
   code point fields to end class
   properties remain roughly the same while codepoints may change.

   The proposed Interconnection class and codepoint scheme tries to
   reflect and consolidate related DiffServ differentiate service quality (see MPLS TC /
   Traffic Class [RFC5462] and QoS standardisation
   efforts outside PCP, Priority Code Point [IEEE802.1Q]).
   The concept of classifying DiffServ traffic classes by the IETF, namely MEF, GSMA and ITU.

   IP Precedence bits 0-2
   of a DSCP has been deprecated when part of Diffserv from start on.  This is also
   reflected by the DiffServ was standardised. codepoint definitions of AF and EF.  It is
   common practice today however also to copy the DSCPs Bits 0-2 (called these three DSCP Precedence Prefix in the following) bits into MPLS TC
   or Ethernet P-Bits.  This is also reflected by the DiffServ codepoint definitions
   of AF and EF.  Class based  PHBs based on DSCP bit 0-2 classification may be
   applied in core network sections rather than then DSCP based PHBs.

   The set
   Network providers make use of available router and traffic management tools this feature for their own IP QoS
   concepts.  This draft suggests to configure expand it to interconnections
   between operators of different domains in a simple manner while each
   operator may maintain the own class and operate DiffServ classes codepoint scheme within the
   own domain.

   The scope of this draft is limited.  This should be reflected by
   class definitions.  These may limited to 4 specified interconnection
   classes having four different 3 bit code points in DSCP bits 0-2.
   Using more than the end be 4 proposed IP precedences at interconnection
   could result in non-revertible IP Precedence or DSCP rewrites and
   avoid sustaining end-to-end QoS classes, if a receiving provider
   operates more related to transport
   properties than to application requirements.  Please interpret
   transport properties as "congestion aware" 4 MPLS TCs.  Assume a provider operating 4 QoS
   classes available at interconnection and "not congestion aware"
   rather then TCP or UDP.

   Finally, MPLS within his backbone.
   Further assume this draft proposes carrier to leave some lass Selector Codepoint
   and by that support MPLS TC codepoint space based ECN marking and
   assume this carrier to allow operate a newtork control class with an own
   MPLS TC.  Two codepoints are left for future DiffServ
   extensions like ECN/PCN and domain internal classes.  An example for use.  If 5 or more PHBs
   each with different DSCP bits 0-2 are offerd at an interconnection
   point and no more than a single MPLS label needs to be pushed, two
   (or more) PHBs will carry the same DSCP bits 0-2 after re-marking to
   the provider internal PHB QoS scheme.  Due to MPLS pen ultimate hop
   popping, DSCPs must be re-written in this case.  That may work if
   bits 3-5 of the DSCP can be CS6.  Some operators protect their network
   internal routing and / or management varied without introducing ambiguities.
   Should this traffic by CS6.  This PHB is
   possibly not available to transport customer or later pass another QoS interconnection
   partner signaling and management traffic.

   In addition to point
   further downstream, the standardisation activities which triggered this
   work, other authors published RFCs or drafts which orginal sending domain may benefit from
   an not be able to
   ensure proper class mapping for the PHBs merged into a single class
   by the receiving domain.

   At first glance, the interconnection class- and codepoint scheme.  RFC 5160 suggests
   Meta-QoS-Classes scheme looks like an
   additional effort.  But there are some obvious benefits: each party
   sending or receiving traffic has to enable deployment of standardised end specify the mapping from or to end QoS
   classes [RFC5160].  The authors agree that
   the proposed interconnection class- class and codepoint code point scheme as well as the idea of
   standardised end only once.  Without
   it, this is to end classes would complement their own work.
   Work on signaling Class of Service at be negotiated per interconnection interfaces by
   BGP [I-D.knoll-idr-cos-interconnect], [ID.idr-sla] is beyond the
   scope party individually.
   Further, end-to-end QoS in terms of this draft.  Should traffic being classified for the basic transport and
   same class properties
   be standardised as proposed here, signaled access to QoS classes may in all passed domains is more likely to result if an
   interconnection code point scheme is used.  It is not necessarily
   resulting from individual per provider mapping negotiations, as can
   be of interest. seen from the example given above.

   The current BGP drafts focus on exchanging SLA standards and
   traffic conditioning parameters.  They seem deployments known to assume that common
   interpretation of the PHB properties identified by DSCPs has been
   established prior author of this draft are
   limited to exchanging further details by BGP signaling.

1.1.  Requirements Language 4 DiffServ classes at interconnection points (or less).
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" example given in RFC 5127 on aggregation of DiffServ service
   classes picks 4 Treatment aggregates (note that this document are prefers
   class instead of treatment aggregate).  Reasons to favour working
   with 4 DiffServ interconnection classes:

   o  There should be interpreted as described in RFC 2119 [RFC2119].

2.  Terminology a coding reserve for interconnection classes.
      This draft re-uses existing terminology.

   DSCP Precedence Prefix leaves space for future standards, for private bilateral
      agreements and for provider internal classes.

   o  The fields available for carrying QoS information (e.g., DiffServ
      PHB) in MPLS and Ethernet are only 3 bits 0-2 of the DSCP (marked "x" in this
           generic DSCP field: xxxddd) size, and are called
      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.

   IP Precedence has been deprecated when DiffServ was standardised.  It
   is common practice today however to copy the DSCPs Bits 0-2 (called
   DSCP Precedence Prefix [RFC2474] in the following.  By ignoring the value of
           bits 3-6 ( d stands for don' care), a simple aggregation of
           PHBs differed by DSCP is possible in IP and following) into MPLS backbones,
           but also if TC or Ethernet transport is applied.
   P-Bits.  This is discussed
           in more detail below.

   Class   A class is a set of one or more PHBs utilising the same PHB
           if classified also reflected by a single identical DSCP Precedence Prefix
           (e.g. an the DiffServ codepoint definitions
   of AF class [RFC2597]).  It is a PHB Scheduling and EF.  Class
           [RFC3260] or an Ordered Aggregate.  A class is a PHB group
           [RFC2575].  Different classes must not based PHBs may be aggregated.

   PHB     On IP layer, a single applied in core network
   sections rather than then DSCP identifies a single PHB.  In
           addition, this document proposes an MPLS like classification
           of traffic for a single PHB based on the DSCP Precedence
           Prefix (see [RFC3270]). PHBs.

   The above references may be incomplete set of available router and mostly refer traffic management tools to the early configure
   and operate DiffServ RFCs only.

   To gain clarity, "DSCP based PHB selection" classes is only meant if
   expressed exactly that way limited.  This should be reflected by
   class definitions.  These may in the remaining document.  "PHB" here
   relates to DSCP Precedence Prefix based PHB selection.

   The following current practice issues relate end be more related to transport
   properties (e.g., whether the concept of the
   DiffServ interconnection class proposal rather than to terminology.
   They serve as additional motivation of this activity:

   o  Abstract class names like "EF" are preferential over those being
      close to an application, like "Voice".  Unfortunately, non QoS
      experts can't handle abstract traffic in a class names.  Hence and usually
      sooner than later, classes are named for applications is congestion
   controlled or groups of
      them.  One consequence however is, that people tend not) than to combine application group class names and SLA parameters.  Based requirements.

   RFC5127 provides recommendations on an
      application specific name domain internal aggregation of
   DiffServ traffic and some worst case performance numbers
      on a paper, they often decide that their application needs offers a
      separate new QoS class.

   o  Worse than that, but very present in practice, is the class
      abstraction level which is preferred by those dealing with QoS (as
      experts or non experts): deployment example [RFC5127].  This
   draft differs from the DSCPs or RFC5127 aggregation deployment example in the DSCP Precedence Prefix
      values.  These are
   following points:

   o  the commodity abstractions applied for QoS
      classes.  Most basic concept of these persons have fixed class this draft is to codepoint
      mappings maintain classes, while
      expecting DSCP remarking at provider edges.

   o  This draft follows RFC4594 in their minds, which they can't easily adapt the proposed marking of provider
      Network Control traffic and expands RFC4594 on per
      customer or per treatment of CS6
      marked traffic at interconnection partner basis.

   While these issues aren't to be solved by IETF (QoS experts could points (see section 5.2).

   The proposed Interconnection class and
   should of course teach staff code point scheme tries to use proper Diffserv terminology
   reflect and
   concepts), a simple consolidate related DiffServ and comprehensible QoS interconnection class
   scheme also is helpful in this area.

3.  Aggregating PHBs of a class by a DSCP Precedence Prefix

   Operation standardisation
   efforts outside of IP and MPLS networks the IETF, namely MEF [MEF 23.1], GSMA [IR.34] and router configuration
   ITU [Y.1566].  GSMAs IR.34 specifies an inter provider VPN, but it is
   simplified, if DSCP based PHBs can be aggregated into
   nevertheless specifying a single class
   by simply classifying them by their DSCP Precedence Prefix.  As
   specified above, the DSCP Precedence Prefix are the bits 0-2 od the
   DSCP.  If classification kind of DiffServ aware IP based on DSCP Precedence Prefix is applied
   in an MPLS domain, the DSCP Precedence Prefix my simply be copied
   into carrier
   interconnection.

1.1.  Related work

   In addition to the MPLS TC field.  This is very useful in domains operating
   Pen-ultimate hop popping.  Also in standardisation activities which triggered this case, operation
   work, other authors published RFCs or drafts which may benefit from
   an interconnection class- and
   configuration codepoint scheme.  RFC 5160 suggests
   Meta-QoS- Classes to enable deployment of routers can be simplified significantly standardised end to end QoS
   classes [RFC5160].  The authors agree that the proposed
   interconnection class- and codepoint scheme as compared well as the idea of
   standardised end to aggregation schemes based end classes would complement their own work.
   Work on configuring individual DSCPs.

   A network provider applying 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 the basic transport and class properties
   be standardised as proposed here, signaled access to QoS classes may
   be of interest.  The current BGP drafts focus on exchanging SLA and
   traffic conditioning parameters.  They seem to assume that common
   interpretation of the PHB properties identified by DSCPs has been
   established prior to exchanging further details by BGP signaling.

2.  Terminology

   This draft re-uses existing terminology.

   DSCP Precedence Prefix based aggregation
   MAY remark incoming DSCPs so  Bits 0-2 of the DSCP ("x" in this generic
           DSCP: xxxddd) are called the DSCP Precedence Prefix.  Section
           4.2 of [RFC2474] discusses the role of these bits in enabling
           use of DiffServ with network equipment that they is not fully
           DiffServ- compliant; this term provides a formal for these
           bits that is preferable to referring to them as "the former
           IP Precedence field".

   DSCP Precedence Class  This is a set of one or more PHBs that utilize
           the same DSCP Precedence Prefix on an interconnection between
           two networks.

3.  Aggregating PHBs of a class by a DSCP Precedence Prefix

   Configuration and operation of MPLS networks is simplified, if a DSCP
   Precedence Class can be aggregated into a single PSC by classifying
   them on their DSCP Precedence Prefix.  The DSCP Precedence Prefix of
   an interconnection DSCP Precedence Class may be rewritten at the
   ingress edge router and then simply be copied into the MPLS TC field
   of one or more labels to be pushed.

   To allow for simple carrier interconnection agreements, carriers
   sending traffic belonging to the same class but marked by DSCPs with
   differing DSCP Precedence Prefixes SHOULD should apply the interconnection
   marking and codepoint code point scheme specified below, if they interconnect
   to a carrier applying DSCP Precedence Prefix based traffic
   aggregation.  An example where this may be required applicable is the
   Interactive Class of GSMA IR.34 [IR.34] (note that the author of this
   draft believes that the GSMA specification is breaking RFC 2597). [IR.34]).  Another option is to
   negotiate a customised interconnection agreement of course.

   A node forwarding traffic based the

   Classification by DSCP Precedence Prefix MUST
   classify this traffic by the DSCP bits 0-2 and it MUST ignore the
   bits 4-6 of DSCP for classification.  Classification by DSCP
   Precedence Prefix is useful for links aggregating DiffServ traffic. is useful for links
   aggregating DiffServ traffic.  DSCP Precedence Prefix based
   classification is not recommended as a general mode of operation.
   Edge systems, QoS policy enforcement nodes, service areas and hosts
   benefit from fine grained DSCP based classification and should
   continue to do so.

   RFC 2474 specifies the Class Selector Codepoints [RFC2474].  These
   offer a similar concept, but they are strictly limited to xxx000
   DSCPs.  The Class Selector Codepoints Code points don't offer aggregation, they
   just simplify classification.  This draft intents to aggregate
   several PHBs of a single class by a DSCP Precedence Prefix, which a
   different concept than that of the Class Selector Codepoints. Code points.

4.  An Interconnection class and codepoint scheme

   DiffServ deployments mostly follow loose class specification schemes
   (often one or two AF classes, EF and Best Effort).  Especially DSCP
   assignment for the AF classes varies between deployments.  Basic AF
   class property definitions are often similar however.  Applying
   provider specific DSCPs is in line with the DiffServ architecture.
   This document doesn't propose to change that.

   Interconnecting parties face the problem of matching classes to be
   interconnected and then to agree on codepoint code point mapping.  As stated by
   draft
   the DiffServ problem statement
   [I-D.polk-tsvwg-diffserv-stds-problem-statement], Architecture [RFC2475], remarking is a standard
   behaviour at interconnection interfaces.  This draft proposes a
   standard interconnection set of 4 QoS DSCP precedence classes with well
   defined DSCP and DSCP Precedence Prefix values.  A sending party
   remarks DSCPs from internal schemes to the Interconnection
   codepoints. code
   points.  The receiving party remarks DSCP Precedence Prefixes and /
   or DSCPs to her internal scheme.  Thus the interconnection
   codepoint code point
   scheme fully complies with the DiffServ architecture.  An

   This draft picks up the DiffServ interconnection class and codepoint scheme was introduced defintions
   proposed by ITU-T
   [Y.1566] (there also including Ethernet).  It is specified Y.1566 [Y.1566].  In addition to the classes
   defined there, this draft proposes a
   higher level complete set of detail in this document.

   At first glance, this looks like an additional effort.  But there are
   obvious benefits: each party sending or receiving traffic has to
   specify the mapping from or to the interconnection class PHBs and
   codepoint scheme only once.  Without it, this is to be negotiated per
   interconnection party individually.  Further, end-to-end QoS DSCPs.
   Like in terms
   of traffic being classified for the same example given by RFC 5127 for domain internal class in all passed domains
   is likely to result if an
   aggregation, Y.1566 specifies four PHB scheduling classes (for
   provider interconnection codepoint scheme is used.
   It is not necessarily resulting however).  Their properties slightly from individual per network mapping
   negotiations.
   those of the RFC5127 example:

   Class Priority:  PHB EF, DSCP 101 110.  The standards and deployments known figures of merit
           describing the PHB to be in the author range of this draft are
   limited low single digit
           milliseconds.  See [RFC3246].  This class corresponds to 4 DiffServ classes at interconnection points (or
   less).Draft RFC 4597 update [I-D.polk-tsvwg-rfc4594-update]doesn't
   seem to generally contradict to this, as
           5127's real time class, but it proposes is limited to standardise
   "many services classes, not all will be used in each network at any
   period traffic for
           which node configuration "ensures that the service rate of time."  Some reasons favour working with 4 DiffServ
   interconnection classes:

   o  There 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:  PHB AF41, DSCP 100 010 (the other AF4 PHB group
           PHB's and DSCPs should be a coding reserve for interconnection classes.
      This leaves space reserved for future standards, for private bilateral
      agreements and for provider internal classes.

   o  MPLS and Ethernet support only 8 PHBs, classes or ECN indications.
      Assignment extension of 3 bit codepoints
           this DSCP scheduling class).  Optimised for whatever purpose low loss, low
           delay, low jitter at high bandwidth.  Traffic load in this
           class must be well
      thought through.  Limiting interconnection QoS controlled, e.g. by application servers.  One
           example could be flow admission control.  There may be
           infrequent retransmissions requested by the application layer
           to four classes 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 to carry multimedia traffic, it is
      MPLS recommended
           to carry audio and Ethernet friendly video traffic in a single PHB (note that sense.

   o  Migrations from one codepoint scheme to another
           video conferencing may require spare
      QoS codepoints.

   The proposed class separate PHBs for audio and codepoint scheme
           video traffic, which could also be realised by utlising two
           AF 4 PHBs).  All of these properties influence the buffer
           design.  This class is designed for point to
   point IP layer interconnections.  Other types of interconnections are
   out of scope transport those parts of this document.
           RFC 5127's Real Time class, which consume considerable QoS
           bandwidth at the interconnection interface.

   Assured:  The basic class complete PHB group AF3, DSCPs 011 010, 011 100 and codepoint scheme
   is applicable 011
           110.  This class may be optimised to transport traffic
           without bandwidth requirements.  It aims on Ethernet layer too.

5.  Consolidation of QoS standards by very low loss at
           high bandwidths.  Retransmissions after losses characterise
           the interconnection codepoint
    scheme

   The interconnection class and codepoint scheme proposed by Y.1566
   also tries to consolidate related DiffServ and QoS standardisation
   efforts outside of influence the IETF [Y.1566]. buffer design.  Active queue
           management with probabilistic dropping may be deployed.  The interconnection
           RFC 5127 example calls this class Assured Elastic.

   Default:  Default PHB, CS0 with DSCP 000 000.  This class and
   codepoint scheme may be a suitable approach to consolidate these
   standards.  MEF 23.1 specifies 3 aggregated classes, consuming up
           optimised to
   5 codepoints on Ethernet layer (EF, AF3, AF1 and Best Effort) and 5
   PHBs [MEF23.1].  MEF aggregates AF1 transport traffic without bandwidth
           requirements.  Retransmissions after losses characterise the
           class and Default PHB in a single
   class.  This is not recommended for interconnection, as it is not in
   line influence the buffer design.  Active queue
           management with probabilistic dropping may be deployed.  The
           RFC 2597 (which requires separate forwarding resources for
   each AF 5127 example calls this class and doesn't foresee aggregation of Default PHB and Elastic.

   The idea is illustrated by an
   AF class).

   GSMA IR.34 proposes four classes, EF, AF4, another AF class example.  Provider O and Best
   Effort provider W are
   peer with 7 PHBs in sum [IR.34].  IR.34 specifies an "Interactive"
   class consisting provider T. They have agreed upon a QoS interconnection.
   Traffic of 3 PHBs with different priorities. provider O terminates within provider Ts network, while
   the GSMA IR.34 assigns traffic transits through the PHBS AF31, AF21 and AF11 netwirk of provider T to this Interactive class.  This breaks
   RFC 2597.  The proposed interconnection class and
   provider F. Assume all providers to run their own internal codepoint scheme
   supports an GSMA Interactive like
   schemes for a class but assigns AF3 with PHBs
   AF31, AF32 and AF33.

   If IETF picks up this draft, it may be properties of the DiffServ Intercon Assured
   class.  See section for a good idea to inform MEF and
   GSMA about conflicts description of their standards with GSMA IR.34.

           Provider-O             Provider-W
           RFC5127                GSMA 34.1
               |                      |
          +----------+           +----------+
          |AF21, AF22|           |AF31, AF21|
          +----------+           +----------+
               |                      |
               V                      V
           +++++++++              +++++++++
           |Rtr PrO|              |Rtr PrW|
           +++++++++              +++++++++
               |        DiffServ and suggest
   joint activities      |
          +----------+           +----------+
          |AF31, AF32|           |AF31, AF32|
          +----------+           +----------+
               |        Intercon      |
               V                      V
           +++++++++                  |
           |RtrPrTI|------------------+
           +++++++++
               |     Provider-T domain
          +-----------+
          | MPLS TC 2 |
          |and  rewr. |
          |DSCP pref 2|
          +-----------+
             |      |  Local DSCPs Provider-T
             |      |  +----------+   +++++++++
             V      +->|AF21, AF22|->-|RtrDstH|
             |         +----------+   +++++++++
         +----------+
         |AF21, AF22|
         +----------+
             |
          +++++++++
          |RtrPrTE|
          +++++++++
             |        DiffServ
         +----------+
         |AF31, AF32|
         +----------+
             |        Intercon
          +++++++++
          |RtrPrHF|
          +++++++++
             |
         +----------+
         |AF31, AF21|
         +----------+
             |
         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 improve exchange traffic in the situation.  Information
   desired classes.

   RFC5127 specifies a separate PHB scheduling class for network control
   traffic.  This class may be present at interconnection interfaces
   too, but depending on
   interworking with MEF 23 and GSMA IR.34 with the interconnection QoS
   scheme could agreement between providers, it may also be given by
   classified for another interconnection class.  See section 4.2 for a later version
   detailed discussion.

   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 draft. document.  The classes to be supported basic class and code point scheme
   is applicable on Ethernet layer too.

4.1.  Treatment of Network Control traffic at carrier interconnection
      interfaces are

   As specified by Y.1566 as:

   Class Priority:  EF, expecting the figures RFC4594, section 3.2, Network Control (NC) traffic
   marked by CS6 is to be expected at interconnection interfaces.  This
   document does not change NC specifications of merit describing RFC4594.  The latter
   specification is detailed on domain internal NC traffic and on
   traffic exchanged between peering points.  Further, it recommends not
   to forward CS6 marked traffic originating from user-controlled end
   points by the
           PHB NC class of a provider domain.

   As a minor clarification to RFC4594, "peering" shouldn't be
   interpreted in a commercial sense.  The NC PHB is applicable also in
   the range of low single digit milliseconds.  See
           [RFC3246].

   Bulk inelastic:  Optimised 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 the application layer 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 to carry multimedia traffic, it is recommended
           to carry audio and video traffic in a single PHB.  All of
           these properties influence the buffer design.

   Assured:  This class may be optimised 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.

   Default:  Default.  This class may be optimised to transport traffic
           without bandwidth requirements.  Retransmissions after losses
           characterise the class and influence the buffer design.
           Active queue management with probabilistic dropping may be
           deployed.

   Note that other DiffServ related standards trim down class
   requirements to SLA parameters.  To quote e.g.  RFC 4594-update, "A
   "service class" represents a similar set of traffic characteristics
   for delay, loss, and jitter as packets traverse routers in a
   network."  This draft adds traffic PHB properties corresponding to
   expected transport layer characteristics as a key factor to a class
   definition: the desired class performance like delay, jitter and
   worst case loss are met only if PHB and transport properties meet the
   ones described by the class definition.  This is not to say, the
   other standards ignore PHB properties.  They are e.g. a core part of
   RFC 4594-update.  They do not directly refer to transport protocol
   properties, as most existing QoS standards prefer the approach of
   assigning QoS classes to applications or application sets.  This may
   result in undesirable class mappings, if an e.g.  IP TV application
   demanding low loss is matched to a class whose low loss guarantees
   depend on AQM mechanisms.

   Y.1566 does not define a complete set of DSCP based PHBs to be
   supported at an interconnection interface.  This information is added
   by this draft.  At interconnection points, the following DSCP based
   PHBs should be accepted between interconnected parties:

   Class:  PHB (one or more)

   Class Priority:  EF

   Bulk inelastic:  AF41 (AF42 and AF43 are reserved for extension)

   Assured:  AF31, AF32 and AF33

   Default:  Default (i.e.  Best Effort)

   Class names (and property specification) have been picked from Y.1566
   above.

6.  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 interconnection interfaces.  This
   document does not change NC specifications of RFC4594.  The latter
   specification is detailed on domain internal NC traffic and on
   traffic exchanged between peering points.  Further, it recommends not
   to forward CS6 marked traffic originating from user-controlled end
   points by the NC class of a provider domain.

   As a minor clarification to RFC4594, "peering" shouldn't be
   interpreted in a commercial sense.  The NC PHB is applicable also in
   the case 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 the domain ingress node (e.g., if BGP is running between
   the two routers on opposite ends of the interconnection link).

   An IP carrier MAY may limit access to the NC PHB for traffic which is
   recognised as network control traffic relevant to the own domain.
   Interconnecting carriers SHOULD 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, if a carrier wishes to send CS6 marked traffic
   accross 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 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 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
      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 other CS6 marked traffic SHOULD should be remarked or dropped.

7.  MPLS, Ethernet and

5.  DiffServ Intercon relation to other QoS standards

   This sections provides suggestions how to aggregate traffic by DSCP
   Precedence Prefixes for aggregated classes Prefexies to Ethernet and MPLS support 3 bit codepoint fields to differentiate
   service quality.  Mapping MPLS.  Other Standardisation
   Organsiations deal with QoS aware provider interconnection.  As IP is
   the state of the DSCP Precedence Prefix to art realisation of provider interconnections, these 3
   Bit fields has been a configuration restriction in the early days
   standards bodies specify DiffServ aware interconnections.  Some of
   DiffServ.  The concept
   these bodies are industry alliances chartered also to promote
   interconnection of classifying DiffServ traffic classes by wireless or Ethernet technology including the
   bits 0-2
   exchange of a DSCP has however been part IP datagrams at interconnection points.  Examples are the
   Metro Ethernet Forum (MEF) or the GSM Alliance (GSMA).  The ITU was
   mentioned earlier.  ITU works across and between responsibilities of Diffserv from start on.
   EF's DSCP Precedence Prefix
   different Standardisation Organisations and liaising with them, if
   their responsibilities are touched, is 5, that traditional part of AF4 is 4 that
   process.

5.1.  MPLS, Ethernet and so on. DSCP Precedence Prefixes for aggregated classes

   The interconnection class and codepoint 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 on Class
      Selector Codepoints. the
      DSCP Precedence Prefix.

   o  it supports a single PHB group (AF3), whose DSCP DSCPs may be
      aggregated into a sinle MPLS TC (or Ethernet priority) based on
      their joint DSCP Precedence Prefix.  This kind of aggregation will
      work for the AF4 PHB group, if the PHBs may AF42 and AF43 need to be
      mapped
      supported in addition to up AF41.

   o  Applying only 4 aggregated classes at interconnection allows for
      bilateral extensions, if desired.  Should two carriers agree to three different
      map AF32 and AF33 to an additional individual MPLS TC's or Ethernet P-Bits.
      Note that TC and offer an
      Ordered Aggregate across the interconnecting domain, this proposal
      at leaves some MPLS TC coding space for such an extension
      (although this draft doesn's favour or recommend doing that, but
      it is possible.  The author isn't aware of deployed service offers
      with 3 different drop levels in a single class. doesn't recommend interconnections of that
      type).

   The above statement is no requirement to depricate any DSCP to MPLS
   TC or Ethernet P-Bit mapping functionality.  In the opposite, by
   limiting the interconnection scheme to 7 DSCP based 6 PHBs, each PHB may be mapped
   to an individual Traffic Class or Priority also within MPLS or
   Ethernet (if desired).

5.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 3 Bit
   telecommunications interconnection model for the exchange of IP based PHB scheme.

8.  QoS class name selection

   This
   traffic between customers of separate mobile 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 more 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 informational discussion, proposed best practice, Inter-Service Provider IP
   Backbone.  This requires an IP QoS aware interconnection as described
   by this draft between IPX provider and Inter-Service Provider IP
   Backbone.

   GSMA IR.34 specifies 4 aggregated classes and mainly relates 7 PHBs.  Mapping to human behaviour (including QoS experts) rather
   than technical issues.  Above the human preference for conceivable
   class names has been mentioned.  Network engineers (including
   DiffServ Intercon is smooth apart from the
   former Diffserv WG authors) recommend avoiding application related
   QoS class names.  Focus should be put on GSMA aggregated class properties.  These can
   be irritating again.  Just looking at SLA parameters like Delay,
   Jitter
   Interactive, which consistfs of 4 PHBs.  The table below lists a
   suggested mapping to DiffServ Intercon.

   |      GSMA IR.34       |  DiffServ-Intercon    |
   |                       |                       |
   |  Agg. Class   |  PHB  |  Agg. Class  |  PHB   |
   +---------------+-------+--------------+--------+
   |Conversational |  EF   |   Priority   |   EF   |
   +---------------+-------+--------------+--------+
   | Streaming     | AF41  |Bulk inelastic|  AF41  |
   +---------------+-------+--------------+--------+
   | Interactive   | AF31  |    Assured   |  AF31  |
   +               +-------+              +--------+
   |  (ordered by  | AF32  |              |        |
   +   priority,   +-------+              +  AF32  +
   | AF3 highest)  | AF21  |              |        |
   +               +-------+              +--------+
   |               | AF11  |              |  AF33  |
   +---------------+-------+--------------+--------+
   | Background    | CS0   |    Default   |   CS0  |
   +---------------+-------+--------------+--------+

   Suggested mapping of GSMA IR.34 classes and packet loss doesn't tell PHBs to DiffServ Intercon

                                 Figure 2

   The motivation resulting in the reader, which transport
   properties guided design of the related scheduler engineering IR.34 Intercative class
   are unknown to the author of this draft.  It is out of scope of this
   draft to decide how 4 PHBs can be mapped to a PHB.  A
   router produces QoS with a scheduling mechanism, a settable queue
   depth to single aggregated
   class.  The suggested mapping is pragmatic and tries to come as close
   as possible to other design criteria pursued by GSMA IR.34.

5.3.  Proposed MEF 23.1 to DiffServ Intercon mapping

   MEF 23.1 is an implemenation agreement facilitating Ethernet service
   interoperability and optional active queue management (including ECN), consistency between Operators and may
   be a policer.  Some kind of resource management may be present (also
   in Diffserv domains).  It's beyond the imagination use of the author how
   one would engineer more than half a dozen classes with
   distinguishable properties using this
   common CoS Label set of tools.

   There's no perfect solution to for Subscribers [MEF23.1].  It pursues the problem, as PHB configurations are
   not comprehensible to most readers, even if they were communicated
   (they are operational secrets of course).  There are (or should be)
   engineering assumptions, when designing QoS PHBs.  They closer relate
   to same
   aims and method on Ethernet layer 3 or as this draft does on IP layer 4 level properties than to specific applications.
   In most cases,
   (i.e. providing an application responds interconnection class and codepoint scheme).  MEF
   23.1 addresses external network to congestion by reducing
   traffic, or it ignores congestion.  Active queue management doesn't
   help network interfaces typically
   interconnecting metro ethernet providers.  This may typically involve
   Ethernet Network Sections associated with typical Operator domains
   that interconnect at external network to avoid congestion in network interfaces.  MEF
   23.1 specifies three aggregated CoS classes.  In addition, the latter case, only resource management
   does.  EF may be usage
   of a special case.  If the EF traffic subset of Ethernet PCP and IP DSCP values is not responsive
   to congestion, specifiedthus
   facilitating synergies between Ethernet and packets IP services and networks.
   The main purpose is specifying operator virtual (Ethernet)
   connections.  As an IP QoS model is added, this draft proposes an IP
   class and codepoint mapping.

   MEF 23.1 QoS mapping requires some thought as 3 classes are assumed to be short, rather small
   jitter values can be reached if engineering ensures that the packet
   arrival rate never exceeds the transmission rate supported
   of that queue (see
   RFC 3246 [RFC3246]).  There's other non congestion-responsive
   traffic, for which the EF engineering assumptions two are Ordered Aggregates.  MEF 23.1s section 8.5.1 example
   on IP DSCP mapping may not fit.  So
   support of a PHB like bulk suggest supporting classification based on the
   DSCP Precedence Prefix.  MEF 23.1 section 8.5.2.1 allows the
   conclusion that MEF class M is best mapped to this drafts Bulk
   inelastic is reasonable.

   Active queue management may be deployed for QoS classes designed class.  The suggested mapping MEF to
   transport traffic responding DiffServ Intercon is
   limited to congestion by traffic reduction.

   The class names the 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 of this document follow Y.1566.  TCP_optimised MEF 23.1 color blind mode classes and
   especially UDP_optimised are inappropriate class names, as some UDP
   based applications are or may be expected PHBs to become TCP friendly.

9.  Allow for
   DiffServ extendibility on MPLS Intercon

                                 Figure 3

   The MEF color aware mode supports Ordered Aggregates in the MEF
   classes M and Ethernet level

   Any aggregated Diffserv deployment faces codepoint depletion issues
   rather soon, if deployed on MPLS or Ethernet.  Coding space should be
   left for new features, like ECN, PCN or Conex.  In addition to
   carrying customer traffic, internal routing L. The MEF L specification classifies AF1 and network management Best
   Effort for the same Ordered Aggregate.  A Better than Best Effort
   service produced in the same queue as best effort traffic may can be protected
   realized, but hasn't been standardized by using a separate IETF.  This document
   doesn't suggest any mapping.  Diffserv Intercon also doesn't suggest
   an Ordered Aggregate in the Bulk Inelastic class.  Offering
   interconnection with up to four classes  Later versions of
   this document may do so and 4 - 6 MPLS TC's (or
   Ethernet P-bits) to that respect is probably at least specify a fair
   compromise.

10.  Acknowledgements solution.  Both issues are left
   for bilateral negotiation.

6.  Contributors

   David Black gave provided many helpful comments and inputs to this work.

7.  Acknowledgements

   Al Morton and Sebastien Jobert provided feedback on many aspects
   during private discussions.  Brian Carpenter, Mohamed Boucadair and
   Thomas Knoll helped adding awareness of further potentially related work.

11.

8.  IANA Considerations

   This memo includes no request to IANA.

12.

9.  Security Considerations

   This document does not introduce new features, it describes how to
   use existing ones.  The security section of RFC 4597 [RFC4597]
   applies.

13. 2475 [RFC2475] and
   RFC 4594 [RFC4594] apply.

10.  References

13.1.

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

   [RFC2575]  Wijnen, B., Presuhn, R.,

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and K. McCloghrie, "View-based
              Access Control Model (VACM) W. Weiss, "An Architecture for the Simple Network
              Management Protocol (SNMP)", Differentiated
              Services", RFC 2575, April 1999. 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.

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

13.2.

10.2.  Informative References

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

   [I-D.polk-tsvwg-diffserv-stds-problem-statement]
              Polk, J., "The Problem Statement for the Standard
              Configuration of DiffServ Service Classes",
              draft-polk-tsvwg-diffserv-stds-problem-statement-00 (work
              in progress), July 2012.

   [I-D.polk-tsvwg-rfc4594-update]
              Polk, J., "Standard Configuration of DiffServ Service
              Classes", draft-polk-tsvwg-rfc4594-update-03
              draft-knoll-idr-cos-interconnect-11 (work in progress), March
              November 2013.

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

   [RFC4597]  Even, R.

   [RFC4594]  Babiarz, J., Chan, K., and N. Ismail, "Conferencing Scenarios", F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4597, 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.

Author's Address

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

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