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

Abstract

This document proposes a limited and well defined set of QoS PHBs and PHB groups to be applied at (inter)connections of 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 August 18, 2014.

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
• 1.1. Related work
• 2. Terminology
• 3. Aggregating PHBs of a class by a DSCP Precedence Prefix
• 4. An Interconnection class and codepoint scheme
• 4.1. Treatment of Network Control traffic at carrier interconnection interfaces
• 5. DiffServ Intercon relation to other QoS standards
• 5.1. MPLS, Ethernet and DSCP Precedence Prefixes for aggregated classes
• 5.2. Proposed GSMA IR.34 to DiffServ Intercon mapping
• 5.3. Proposed MEF 23.1 to DiffServ Intercon mapping
• 6. Contributors
• 7. Acknowledgements
• 8. IANA Considerations
• 9. Security Considerations
• 10. References
• 10.1. Normative References
• 10.2. Informative References
• Appendix A. Change log
• Author's Address

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.

IP precedence has been deprecated. MPLS and Ethernet support 3 bit code point fields to differentiate service quality (see MPLS TC / Traffic Class [RFC5462] and PCP, Priority Code Point [IEEE802.1Q]). The concept of classifying DiffServ traffic classes by the bits 0-2 of a DSCP has been part of Diffserv from start on. This is also reflected by the DiffServ codepoint definitions of AF and EF. It is common practice today also to copy these three DSCP bits into MPLS TC or Ethernet P-Bits. PHBs based on DSCP bit 0-2 classification may be applied in core network sections rather than then DSCP based PHBs. Network providers make use of this feature for their own IP QoS concepts. This draft suggests to expand it to interconnections between operators of different domains in a simple manner while each operator may maintain the own class and codepoint scheme within the own domain.

The scope of this draft is limited to 4 specified interconnection classes having four different 3 bit code points in DSCP bits 0-2. Using more than the 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 than 4 MPLS TCs. Assume a provider operating 4 QoS classes available at interconnection and MPLS within his backbone. Further assume this carrier to support MPLS based ECN marking and assume this carrier to operate a newtork control class with an own MPLS TC. Two codepoints are left for future 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 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 varied without introducing ambiguities. Should this traffic later pass another QoS interconnection point further downstream, the orginal sending domain may 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 codepoint scheme looks like an additional effort. But there are some obvious benefits: each party sending or receiving traffic has to specify the mapping from or to the interconnection class and code point scheme only once. Without it, this is to be negotiated per interconnection party individually. Further, end-to-end QoS in terms of traffic being classified for the same class 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 seen from the example given above.

The standards and deployments known to the author of this draft are limited to 4 DiffServ classes at interconnection points (or less). The example given in RFC 5127 on aggregation of DiffServ service classes picks 4 Treatment aggregates (note that this document prefers class instead of treatment aggregate). Reasons to favour working with 4 DiffServ interconnection classes:

• There should be a coding reserve for interconnection classes. This leaves space for future standards, for private bilateral agreements and for provider internal classes.
• The fields available for carrying QoS information (e.g., DiffServ PHB) in MPLS and Ethernet are only 3 bits in size, and are intended for more than just QoS purposes (see e.g. [RFC5129]).
• 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 in the following) into MPLS TC or Ethernet P-Bits. This is also reflected by the DiffServ codepoint definitions of AF and EF. Class based PHBs may be applied in core network sections rather than then DSCP based PHBs.

The set of available router and traffic management tools to configure and operate DiffServ classes is limited. This should be reflected by class definitions. These may in the end be more related to transport properties (e.g., whether the traffic in a class is congestion controlled or not) than to application requirements.

RFC5127 provides recommendations on domain internal aggregation of DiffServ traffic and offers a deployment example [RFC5127]. This draft differs from the RFC5127 aggregation deployment example in the following points:

• the basic concept of this draft is to maintain classes, while expecting DSCP remarking at provider edges.
• This draft 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 and code point scheme tries to reflect and consolidate related DiffServ and 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 is nevertheless specifying a kind of DiffServ aware IP based carrier interconnection.

1.1. Related work

In addition to the standardisation activities which triggered this work, other authors published RFCs or drafts which may benefit from an interconnection class- and codepoint scheme. RFC 5160 suggests Meta-QoS- Classes to enable deployment of standardised end to end QoS classes [RFC5160]. The authors agree that the proposed interconnection class- and codepoint scheme as well as the idea 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 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

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 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 apply the interconnection marking and code point scheme specified below, if they interconnect to a carrier applying DSCP Precedence Prefix based traffic aggregation. An example where this may be applicable is the Interactive Class of GSMA IR.34 [IR.34]). Another option is to negotiate a customised interconnection agreement of course.

Classification by DSCP Precedence Prefix 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 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 Code points.

4. An Interconnection class and codepoint scheme

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

This draft picks up the DiffServ interconnection class defintions proposed by ITU-T Y.1566 [Y.1566]. In addition to the classes defined there, this draft proposes a complete set of PHBs and DSCPs. Like in the example given by RFC 5127 for domain internal class aggregation, Y.1566 specifies four PHB scheduling classes (for provider interconnection however). Their properties slightly from those of the RFC5127 example:

Class Priority:

PHB EF, DSCP 101 110. The figures of merit describing the PHB to be in the range of low single digit milliseconds. See [RFC3246]. This class corresponds to RFC 5127's real time class, but it is limited to traffic for which node configuration "ensures that the service rate 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:

PHB AF41, DSCP 100 010 (the other AF4 PHB group PHB's and DSCPs should be reserved for future extension of this DSCP scheduling class). 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 (note that video conferencing may require separate PHBs for audio and 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 to transport those parts of RFC 5127's Real Time class, which consume considerable QoS bandwidth at the interconnection interface.

Assured:

The complete PHB group AF3, DSCPs 011 010, 011 100 and 011 110. 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. The RFC 5127 example calls this class Assured Elastic.

Default:

Default PHB, CS0 with DSCP 000 000. 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. The RFC 5127 example calls this class Elastic.

The idea is illustrated by an example. Provider O and provider W are peer with provider T. They have agreed upon a QoS interconnection. Traffic of provider O terminates within provider Ts network, while the GSMA IR.34 traffic transits through the netwirk of provider T to provider F. Assume all providers to run their own internal codepoint schemes for a class with properties of the DiffServ Intercon Assured class. See section for a description of GSMA IR.34.

        Provider-O             Provider-W
        RFC5127                GSMA 34.1
            |                      |
       +----------+           +----------+
       |AF21, AF22|           |AF31, AF21|
       +----------+           +----------+
            |                      |
            V                      V
        +++++++++              +++++++++
        |Rtr PrO|              |Rtr PrW|
        +++++++++              +++++++++ 
            |        DiffServ      |
       +----------+           +----------+
       |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               
    

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

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