draft-geib-tsvwg-diffserv-intercon-04.txt   draft-geib-tsvwg-diffserv-intercon-05.txt 
TSVWG R. Geib, Ed. TSVWG R. Geib, Ed.
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Intended status: Informational October 18, 2013 Intended status: Informational February 14, 2014
Expires: April 21, 2014 Expires: August 18, 2014
DiffServ interconnection classes and practice DiffServ interconnection classes and practice
draft-geib-tsvwg-diffserv-intercon-04 draft-geib-tsvwg-diffserv-intercon-05
Abstract Abstract
This document proposes a limited set of interconnection QoS PHBs and This document proposes a limited and well defined set of QoS PHBs and
PHB groups. It further introduces some DiffServ deployment aspects. PHB groups to be applied at (inter)connections of two separately
The proposals made here should be integrated into a revised version administered and operated networks. Many network providers operate
of RFC5127. Aggregated DiffServ classes. This draft contains DiffServ
aggregation friendly interconnection concepts.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Aggregating PHBs of a class by a DSCP Precedence Prefix . . . 5 3. Aggregating PHBs of a class by a DSCP Precedence Prefix . . . 6
4. An Interconnection class and codepoint scheme . . . . . . . . 6 4. An Interconnection class and codepoint scheme . . . . . . . . 6
5. Consolidation of QoS standards by the interconnection 4.1. Treatment of Network Control traffic at carrier
codepoint scheme . . . . . . . . . . . . . . . . . . . . . . . 7 interconnection interfaces . . . . . . . . . . . . . . . . 9
6. Treatment of Network Control traffic at carrier 5. DiffServ Intercon relation to other QoS standards . . . . . . 10
interconnection interfaces . . . . . . . . . . . . . . . . . . 9 5.1. MPLS, Ethernet and DSCP Precedence Prefixes for
7. MPLS, Ethernet and DSCP Precedence Prefixes for aggregated aggregated classes . . . . . . . . . . . . . . . . . . . . 11
classes . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Proposed GSMA IR.34 to DiffServ Intercon mapping . . . . . 11
8. QoS class name selection . . . . . . . . . . . . . . . . . . . 11 5.3. Proposed MEF 23.1 to DiffServ Intercon mapping . . . . . . 12
9. Allow for DiffServ extendibility on MPLS and Ethernet level . 12 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This draft proposes a DiffServ interconnection class and codepoint DiffServ has been deployed in many networks. As described by section
scheme. At least one party of an interconnection often is a network 2.3.4.2 of RFC 2475, remarking of packets at domain boundaries is a
provider. Many network providers operate Aggregated DiffServ DiffServ feature [RFC2475]. This draft proposes a set of standard
classes. This draft contains concepts and current practice relevant QoS classes and code points at interconnection points to which and
for a revised version of RFC5127 [RFC5127]. Its main purpose is to from which locally used classes and code points should be mapped.
be considered as an input for the latter task.
DiffServ sees deployment in many networks for the time being. As IP precedence has been deprecated. MPLS and Ethernet support 3 bit
described in the introduction of the draft DiffServ problem statement code point fields to differentiate service quality (see MPLS TC /
[I-D.polk-tsvwg-diffserv-stds-problem-statement], remarking of Traffic Class [RFC5462] and PCP, Priority Code Point [IEEE802.1Q]).
packets at domain boundaries is a DiffServ feature. This draft The concept of classifying DiffServ traffic classes by the bits 0-2
proposes a set of standard QoS classes and codepoints at of a DSCP has been part of Diffserv from start on. This is also
interconnection points to which and from which locally used classes reflected by the DiffServ codepoint definitions of AF and EF. It is
and codepoints should be mapped. Such a scheme simplifies common practice today also to copy these three DSCP bits into MPLS TC
interconnection negotiations and ensures that end to end class or Ethernet P-Bits. PHBs based on DSCP bit 0-2 classification may be
properties remain roughly the same while codepoints may change. 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 proposed Interconnection class and codepoint scheme tries to The scope of this draft is limited to 4 specified interconnection
reflect and consolidate related DiffServ and QoS standardisation classes having four different 3 bit code points in DSCP bits 0-2.
efforts outside of the IETF, namely MEF, GSMA and ITU. 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:
o There should be a coding reserve for interconnection classes.
This 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 in size, and are
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 IP Precedence has been deprecated when DiffServ was standardised. It
is common practice today however to copy the DSCPs Bits 0-2 (called is common practice today however to copy the DSCPs Bits 0-2 (called
DSCP Precedence Prefix in the following) into MPLS TC or Ethernet DSCP Precedence Prefix in the following) into MPLS TC or Ethernet
P-Bits. This is also reflected by the DiffServ codepoint definitions P-Bits. This is also reflected by the DiffServ codepoint definitions
of AF and EF. Class based PHBs may be applied in core network of AF and EF. Class based PHBs may be applied in core network
sections rather than then DSCP based PHBs. sections rather than then DSCP based PHBs.
The set of available router and traffic management tools to configure The set of available router and traffic management tools to configure
and operate DiffServ classes is limited. This should be reflected by and operate DiffServ classes is limited. This should be reflected by
class definitions. These may in the end be more related to transport class definitions. These may in the end be more related to transport
properties than to application requirements. Please interpret properties (e.g., whether the traffic in a class is congestion
transport properties as "congestion aware" and "not congestion aware" controlled or not) than to application requirements.
rather then TCP or UDP.
Finally, this draft proposes to leave some lass Selector Codepoint RFC5127 provides recommendations on domain internal aggregation of
and by that MPLS TC codepoint space to allow for future DiffServ DiffServ traffic and offers a deployment example [RFC5127]. This
extensions like ECN/PCN and domain internal classes. An example for draft differs from the RFC5127 aggregation deployment example in the
an internal PHB may be CS6. Some operators protect their network following points:
internal routing and / or management traffic by CS6. This PHB is
possibly not available to transport customer or interconnection o the basic concept of this draft is to maintain classes, while
partner signaling and management traffic. expecting DSCP remarking at provider edges.
o 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 In addition to the standardisation activities which triggered this
work, other authors published RFCs or drafts which may benefit from work, other authors published RFCs or drafts which may benefit from
an interconnection class- and codepoint scheme. RFC 5160 suggests an interconnection class- and codepoint scheme. RFC 5160 suggests
Meta-QoS-Classes to enable deployment of standardised end to end QoS Meta-QoS- Classes to enable deployment of standardised end to end QoS
classes [RFC5160]. The authors agree that the proposed classes [RFC5160]. The authors agree that the proposed
interconnection class- and codepoint scheme as well as the idea of interconnection class- and codepoint scheme as well as the idea of
standardised end to end classes would complement their own work. standardised end to end classes would complement their own work.
Work on signaling Class of Service at interconnection interfaces by Work on signaling Class of Service at interconnection interfaces by
BGP [I-D.knoll-idr-cos-interconnect], [ID.idr-sla] is beyond the BGP [I-D.knoll-idr-cos-interconnect], [ID.idr-sla] is beyond the
scope of this draft. Should the basic transport and class properties scope of this draft. Should the basic transport and class properties
be standardised as proposed here, signaled access to QoS classes may be standardised as proposed here, signaled access to QoS classes may
be of interest. The current BGP drafts focus on exchanging SLA and be of interest. The current BGP drafts focus on exchanging SLA and
traffic conditioning parameters. They seem to assume that common traffic conditioning parameters. They seem to assume that common
interpretation of the PHB properties identified by DSCPs has been interpretation of the PHB properties identified by DSCPs has been
established prior to exchanging further details by BGP signaling. established prior to exchanging further details by BGP signaling.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
This draft re-uses existing terminology. This draft re-uses existing terminology.
DSCP Precedence Prefix The bits 0-2 of the DSCP (marked "x" in this DSCP Precedence Prefix Bits 0-2 of the DSCP ("x" in this generic
generic DSCP field: xxxddd) are called the DSCP Precedence DSCP: xxxddd) are called the DSCP Precedence Prefix. Section
Prefix [RFC2474] in the following. By ignoring the value of 4.2 of [RFC2474] discusses the role of these bits in enabling
bits 3-6 ( d stands for don' care), a simple aggregation of use of DiffServ with network equipment that is not fully
PHBs differed by DSCP is possible in IP and MPLS backbones, DiffServ- compliant; this term provides a formal for these
but also if Ethernet transport is applied. This is discussed bits that is preferable to referring to them as "the former
in more detail below. IP Precedence field".
Class A class is a set of one or more PHBs utilising the same PHB
if classified by a single identical DSCP Precedence Prefix
(e.g. an AF class [RFC2597]). It is a PHB Scheduling Class
[RFC3260] or an Ordered Aggregate. A class is a PHB group
[RFC2575]. Different classes must not be aggregated.
PHB On IP layer, a single 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]).
The above references may be incomplete and mostly refer to the early
DiffServ RFCs only.
To gain clarity, "DSCP based PHB selection" is only meant if
expressed exactly that way in the remaining document. "PHB" here
relates to DSCP Precedence Prefix based PHB selection.
The following current practice issues relate to 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 class names. Hence and usually
sooner than later, classes are named for applications or groups of
them. One consequence however is, that people tend to combine
application group class names and SLA parameters. Based on an
application specific name and some worst case performance numbers
on a paper, they often decide that their application needs 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): the DSCPs or the DSCP Precedence Prefix
values. These are the commodity abstractions applied for QoS
classes. Most of these persons have fixed class to codepoint
mappings in their minds, which they can't easily adapt on per
customer or per interconnection partner basis.
While these issues aren't to be solved by IETF (QoS experts could and DSCP Precedence Class This is a set of one or more PHBs that utilize
should of course teach staff to use proper Diffserv terminology and the same DSCP Precedence Prefix on an interconnection between
concepts), a simple and comprehensible QoS interconnection class two networks.
scheme also is helpful in this area.
3. Aggregating PHBs of a class by a DSCP Precedence Prefix 3. Aggregating PHBs of a class by a DSCP Precedence Prefix
Operation of IP and MPLS networks and router configuration is Configuration and operation of MPLS networks is simplified, if a DSCP
simplified, if DSCP based PHBs can be aggregated into a single class Precedence Class can be aggregated into a single PSC by classifying
by simply classifying them by their DSCP Precedence Prefix. As them on their DSCP Precedence Prefix. The DSCP Precedence Prefix of
specified above, the DSCP Precedence Prefix are the bits 0-2 od the an interconnection DSCP Precedence Class may be rewritten at the
DSCP. If classification based on DSCP Precedence Prefix is applied ingress edge router and then simply be copied into the MPLS TC field
in an MPLS domain, the DSCP Precedence Prefix my simply be copied of one or more labels to be pushed.
into the MPLS TC field. This is very useful in domains operating
Pen-ultimate hop popping. Also in this case, operation and
configuration of routers can be simplified significantly as compared
to aggregation schemes based on configuring individual DSCPs.
A network provider applying DSCP Precedence Prefix based aggregation To allow for simple carrier interconnection agreements, carriers
MAY remark incoming DSCPs so that they can be aggregated by their sending traffic belonging to the same class but marked by DSCPs with
DSCP Precedence Prefix. To allow for simple carrier interconnection differing DSCP Precedence Prefixes should apply the interconnection
agreements, carriers sending traffic belonging to the same class but marking and code point scheme specified below, if they interconnect
marked by DSCPs with differing DSCP Precedence Prefixes SHOULD apply to a carrier applying DSCP Precedence Prefix based traffic
the interconnection marking and codepoint scheme specified below, if aggregation. An example where this may be applicable is the
they interconnect to a carrier applying DSCP Precedence Prefix based Interactive Class of GSMA IR.34 [IR.34]). Another option is to
traffic aggregation. An example where this may be required is the negotiate a customised interconnection agreement of course.
Interactive Class of GSMA IR.34 [IR.34] (note that the author of this
draft believes that the GSMA specification is breaking RFC 2597).
Another option is to negotiate a customised interconnection agreement
of course.
A node forwarding traffic based the DSCP Precedence Prefix MUST Classification by DSCP Precedence Prefix is useful for links
classify this traffic by the DSCP bits 0-2 and it MUST ignore the aggregating DiffServ traffic. DSCP Precedence Prefix based
bits 4-6 of DSCP for classification. Classification by DSCP classification is not recommended as a general mode of operation.
Precedence Prefix is useful for links aggregating DiffServ traffic. Edge systems, QoS policy enforcement nodes, service areas and hosts
DSCP Precedence Prefix based classification is not recommended as a benefit from fine grained DSCP based classification and should
general mode of operation. Edge systems, QoS policy enforcement continue to do so.
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 RFC 2474 specifies the Class Selector Codepoints [RFC2474]. These
offer a similar concept, but they are strictly limited to xxx000 offer a similar concept, but they are strictly limited to xxx000
DSCPs. The Class Selector Codepoints don't offer aggregation, they DSCPs. The Class Selector Code points don't offer aggregation, they
just simplify classification. This draft intents to aggregate just simplify classification. This draft intents to aggregate
several PHBs of a single class by a DSCP Precedence Prefix, which a several PHBs of a single class by a DSCP Precedence Prefix, which a
different concept than that of the Class Selector Codepoints. different concept than that of the Class Selector Code points.
4. An Interconnection class and codepoint scheme 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 Interconnecting parties face the problem of matching classes to be
interconnected and then to agree on codepoint mapping. As stated by interconnected and then to agree on code point mapping. As stated by
draft DiffServ problem statement the DiffServ Architecture [RFC2475], remarking is a standard
[I-D.polk-tsvwg-diffserv-stds-problem-statement], remarking is a behaviour at interconnection interfaces. This draft proposes a
standard behaviour at interconnection interfaces. This draft standard interconnection set of 4 DSCP precedence classes with well
proposes a standard interconnection set of 4 QoS classes with well
defined DSCP and DSCP Precedence Prefix values. A sending party defined DSCP and DSCP Precedence Prefix values. A sending party
remarks DSCPs from internal schemes to the Interconnection remarks DSCPs from internal schemes to the Interconnection code
codepoints. The receiving party remarks DSCP Precedence Prefixes and points. The receiving party remarks DSCP Precedence Prefixes and /
/ or DSCPs to her internal scheme. Thus the interconnection or DSCPs to her internal scheme. Thus the interconnection code point
codepoint scheme fully complies with the DiffServ architecture. An scheme fully complies with the DiffServ architecture.
interconnection class and codepoint scheme was introduced by ITU-T
[Y.1566] (there also including Ethernet). It is specified to a
higher level 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 and
codepoint 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 likely to result if an interconnection codepoint scheme is used.
It is not necessarily resulting from individual per network mapping
negotiations.
The standards and deployments known to the author of this draft are
limited 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 it proposes to standardise
"many services classes, not all will be used in each network at any
period of time." Some reasons favour working with 4 DiffServ
interconnection classes:
o There should be a coding reserve for interconnection classes.
This leaves space 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 of 3 bit codepoints for whatever purpose must be well
thought through. Limiting interconnection QoS to four classes is
MPLS and Ethernet friendly in that sense.
o Migrations from one codepoint scheme to another may require spare
QoS codepoints.
The proposed class and codepoint 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 codepoint scheme
is applicable on Ethernet layer too.
5. Consolidation of QoS standards by 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 the IETF [Y.1566]. The interconnection class and
codepoint scheme may be a suitable approach to consolidate these
standards. MEF 23.1 specifies 3 aggregated classes, consuming up to
5 codepoints on Ethernet layer (EF, AF3, AF1 and Best Effort) and 5
PHBs [MEF23.1]. MEF aggregates AF1 and Default PHB in a single
class. This is not recommended for interconnection, as it is not in
line with RFC 2597 (which requires separate forwarding resources for
each AF class and doesn't foresee aggregation of Default PHB and an
AF class).
GSMA IR.34 proposes four classes, EF, AF4, another AF class and Best
Effort with 7 PHBs in sum [IR.34]. IR.34 specifies an "Interactive"
class consisting of 3 PHBs with different priorities. IR.34 assigns
the PHBS AF31, AF21 and AF11 to this Interactive class. This breaks
RFC 2597. The proposed interconnection class and codepoint scheme
supports an GSMA Interactive like class but assigns AF3 with PHBs
AF31, AF32 and AF33.
If IETF picks up this draft, it may be a good idea to inform MEF and
GSMA about conflicts of their standards with DiffServ and suggest
joint activities to improve the situation. Information on
interworking with MEF 23 and GSMA IR.34 with the interconnection QoS
scheme could be given by a later version of this draft.
The classes to be supported at interconnection interfaces are This draft picks up the DiffServ interconnection class defintions
specified by Y.1566 as: 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: EF, expecting the figures of merit describing the Class Priority: PHB EF, DSCP 101 110. The figures of merit
PHB to be in the range of low single digit milliseconds. See describing the PHB to be in the range of low single digit
[RFC3246]. 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: Optimised for low loss, low delay, low jitter at Bulk inelastic: PHB AF41, DSCP 100 010 (the other AF4 PHB group
high bandwidth. Traffic load in this class must be PHB's and DSCPs should be reserved for future extension of
controlled, e.g. by application servers. One example could this DSCP scheduling class). Optimised for low loss, low
be flow admission control. There may be infrequent delay, low jitter at high bandwidth. Traffic load in this
retransmissions requested by the application layer to class must be controlled, e.g. by application servers. One
mitigate low levels of packet losses. Discard of packets 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 through active queue management should be avoided in this
class. Congestion in this class may result in bursty packet class. Congestion in this class may result in bursty packet
loss. If used to carry multimedia traffic, it is recommended loss. If used to carry multimedia traffic, it is recommended
to carry audio and video traffic in a single PHB. All of to carry audio and video traffic in a single PHB (note that
these properties influence the buffer design. video conferencing may require separate PHBs for audio and
video traffic, which could also be realised by utlising two
Assured: This class may be optimised to transport traffic without AF 4 PHBs). All of these properties influence the buffer
bandwidth requirements. It aims on Very low loss at high design. This class is designed to transport those parts of
bandwidths. Retransmissions after losses characterise the RFC 5127's Real Time class, which consume considerable QoS
class and influence the buffer design. Active queue bandwidth at the interconnection interface.
management with probabilistic dropping may be deployed.
Default: Default. This class may be optimised to transport traffic Assured: The complete PHB group AF3, DSCPs 011 010, 011 100 and 011
without bandwidth requirements. Retransmissions after losses 110. This class may be optimised to transport traffic
characterise the class and influence the buffer design. without bandwidth requirements. It aims on very low loss at
Active queue management with probabilistic dropping may be high bandwidths. Retransmissions after losses characterise
deployed. 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.
Note that other DiffServ related standards trim down class Default: Default PHB, CS0 with DSCP 000 000. This class may be
requirements to SLA parameters. To quote e.g. RFC 4594-update, "A optimised to transport traffic without bandwidth
"service class" represents a similar set of traffic characteristics requirements. Retransmissions after losses characterise the
for delay, loss, and jitter as packets traverse routers in a class and influence the buffer design. Active queue
network." This draft adds traffic PHB properties corresponding to management with probabilistic dropping may be deployed. The
expected transport layer characteristics as a key factor to a class RFC 5127 example calls this class Elastic.
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 The idea is illustrated by an example. Provider O and provider W are
supported at an interconnection interface. This information is added peer with provider T. They have agreed upon a QoS interconnection.
by this draft. At interconnection points, the following DSCP based Traffic of provider O terminates within provider Ts network, while
PHBs should be accepted between interconnected parties: 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.
Class: PHB (one or more) 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
Class Priority: EF DiffServ Intercon example
Bulk inelastic: AF41 (AF42 and AF43 are reserved for extension) Figure 1
Assured: AF31, AF32 and AF33 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.
Default: Default (i.e. Best Effort) RFC5127 specifies a separate PHB scheduling class for network control
traffic. This class may be present at interconnection interfaces
too, but depending on the agreement between providers, it may also be
classified for another interconnection class. See section 4.2 for a
detailed discussion.
Class names (and property specification) have been picked from Y.1566 The proposed class and code point scheme is designed for point to
above. 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.
6. Treatment of Network Control traffic at carrier interconnection 4.1. Treatment of Network Control traffic at carrier interconnection
interfaces interfaces
As specified by RFC4594, section 3.2, Network Control (NC) traffic As specified by RFC4594, section 3.2, Network Control (NC) traffic
marked by CS6 is to be expected at interconnection interfaces. This marked by CS6 is to be expected at interconnection interfaces. This
document does not change NC specifications of RFC4594. The latter document does not change NC specifications of RFC4594. The latter
specification is detailed on domain internal NC traffic and on specification is detailed on domain internal NC traffic and on
traffic exchanged between peering points. Further, it recommends not traffic exchanged between peering points. Further, it recommends not
to forward CS6 marked traffic originating from user-controlled end to forward CS6 marked traffic originating from user-controlled end
points by the NC class of a provider domain. points by the NC class of a provider domain.
As a minor clarification to RFC4594, "peering" shouldn't be As a minor clarification to RFC4594, "peering" shouldn't be
interpreted in a commercial sense. The NC PHB is applicable also in interpreted in a commercial sense. The NC PHB is applicable also in
the case of a purchased network service based on a transit agreement the case of a purchased network service based on a transit agreement
with an upstream provider. RFC4594 recommendations on NC traffic are with an upstream provider. RFC4594 recommendations on NC traffic are
applicable for IP carrier interconnections in general. applicable for IP carrier interconnections in general.
Some CS6 traffic exchanged accross carrier interconnections will Some CS6 traffic exchanged accross carrier interconnections will
terminate at the domain ingress node (e.g., if BGP is running between terminate at the domain ingress node (e.g., if BGP is running between
the two routers on opposite ends of the interconnection link). the two routers on opposite ends of the interconnection link).
An IP carrier MAY limit access to the NC PHB for traffic which is An IP carrier may limit access to the NC PHB for traffic which is
recognised as network control traffic relevant to the own domain. recognised as network control traffic relevant to the own domain.
Interconnecting carriers SHOULD specify treatment of CS6 marked Interconnecting carriers should specify treatment of CS6 marked
traffic received at a carrier interconnection which is to be traffic received at a carrier interconnection which is to be
forwarded beyond the ingress node. An SLA covering the following forwarded beyond the ingress node. An SLA covering the following
cases is recommended, if a carrier wishes to send CS6 marked traffic cases is recommended, if a carrier wishes to send CS6 marked traffic
accross an interconnection link which isn't terminating at the accross an interconnection link which isn't terminating at the
interconnected ingress node: interconnected ingress node:
o classification of traffic which is network control traffic for o classification of traffic which is network control traffic for
both domains. This traffic SHOULD be classified for the NC PHB. both domains. This traffic should be classified and marked for
the NC PHB.
o classification of traffic which is network control traffic for the o classification of traffic which is network control traffic for the
sending domain only. This traffic SHOULD be classified for a PHB sending domain only. This traffic should be classified for a PHB
offering similar properties as the NC class (e.g. AF31 as offering similar properties as the NC class (e.g. AF31 as
specified by this document). 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 be remarked or dropped. o any other CS6 marked traffic should be remarked or dropped.
7. MPLS, Ethernet and DSCP Precedence Prefixes for aggregated classes 5. DiffServ Intercon relation to other QoS standards
Ethernet and MPLS support 3 bit codepoint fields to differentiate This sections provides suggestions how to aggregate traffic by DSCP
service quality. Mapping of the DSCP Precedence Prefix to these 3 Precedence Prefexies to Ethernet and MPLS. Other Standardisation
Bit fields has been a configuration restriction in the early days of Organsiations deal with QoS aware provider interconnection. As IP is
DiffServ. The concept of classifying DiffServ traffic classes by the the state of the art realisation of provider interconnections, these
bits 0-2 of a DSCP has however been part of Diffserv from start on. standards bodies specify DiffServ aware interconnections. Some of
EF's DSCP Precedence Prefix is 5, that of AF4 is 4 and so on. The these bodies are industry alliances chartered also to promote
interconnection class and codepoint scheme respects properties and interconnection of wireless or Ethernet technology including the
limits of a 3 bit PHB coding space in different ways: exchange of 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
different Standardisation Organisations and liaising with them, if
their responsibilities are touched, is traditional part of that
process.
o it allows to classify four interconnection classes based on Class 5.1. MPLS, Ethernet and DSCP Precedence Prefixes for aggregated classes
Selector Codepoints.
o it supports a single PHB group (AF3), whose DSCP based PHBs may be The interconnection class and code point scheme respects properties
mapped to up to three different MPLS TC's or Ethernet P-Bits. and limits of a 3 bit PHB coding space in different ways:
Note that this draft doesn's favour or recommend doing that, but
it is possible. The author isn't aware of deployed service offers o it allows to classify four interconnection classes based on the
with 3 different drop levels in a single class. DSCP Precedence Prefix.
o it supports a single PHB group (AF3), whose 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 AF42 and AF43 need to be
supported in addition to AF41.
o Applying only 4 aggregated classes at interconnection allows for
bilateral extensions, if desired. Should two carriers agree to
map AF32 and AF33 to an additional individual MPLS 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't recommend interconnections of that
type).
The above statement is no requirement to depricate any DSCP to MPLS The above statement is no requirement to depricate any DSCP to MPLS
TC or Ethernet P-Bit mapping functionality. In the opposite, by TC or Ethernet P-Bit mapping functionality. In the opposite, by
limiting the interconnection scheme to 7 DSCP based PHBs, each PHB limiting the interconnection scheme to 6 PHBs, each PHB may be mapped
may be mapped to a 3 Bit based PHB scheme. to an individual Traffic Class or Priority also within MPLS or
Ethernet (if desired).
8. QoS class name selection 5.2. Proposed GSMA IR.34 to DiffServ Intercon mapping
This is more of an informational discussion, proposed best practice, GSMA IR.34 provides guidelines on how to set up and interconnect
and mainly relates to human behaviour (including QoS experts) rather Internet Protocol (IP) Packet eXchange (IPX) Networks [IR.34]. An
than technical issues. Above the human preference for conceivable IPX network is an inter-Service Provider IP backbone which comprises
class names has been mentioned. Network engineers (including the the interconnected networks of IPX Providers. IPX is a
former Diffserv WG authors) recommend avoiding application related telecommunications interconnection model for the exchange of IP based
QoS class names. Focus should be put on class properties. These can traffic between customers of separate mobile and fixed operators as
be irritating again. Just looking at SLA parameters like Delay, well as other types of service provider (such as ISP), via IP based
Jitter and packet loss doesn't tell the reader, which transport network-to-network interface. Note that IPX is not a public
properties guided the related scheduler engineering of a PHB. A interconnection model however, it is designed as a private IP
router produces QoS with a scheduling mechanism, a settable queue Backbone of the interconnected parties. Two IPX partners may
depth and optional active queue management (including ECN), and may interconnect using transit offered by an Inter-Service Provider IP
be a policer. Some kind of resource management may be present (also Backbone. This requires an IP QoS aware interconnection as described
in Diffserv domains). It's beyond the imagination of the author how by this draft between IPX provider and Inter-Service Provider IP
one would engineer more than half a dozen classes with Backbone.
distinguishable properties using this set of tools.
There's no perfect solution to the problem, as PHB configurations are GSMA IR.34 specifies 4 aggregated classes and 7 PHBs. Mapping to
not comprehensible to most readers, even if they were communicated DiffServ Intercon is smooth apart from the GSMA aggregated class
(they are operational secrets of course). There are (or should be) Interactive, which consistfs of 4 PHBs. The table below lists a
engineering assumptions, when designing QoS PHBs. They closer relate suggested mapping to DiffServ Intercon.
to layer 3 or layer 4 level properties than to specific applications.
In most cases, an application responds to congestion by reducing
traffic, or it ignores congestion. Active queue management doesn't
help to avoid congestion in the latter case, only resource management
does. EF may be a special case. If the EF traffic is not responsive
to congestion, and packets 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 of that queue (see
RFC 3246 [RFC3246]). There's other non congestion-responsive
traffic, for which the EF engineering assumptions may not fit. So
support of a PHB like bulk inelastic is reasonable.
Active queue management may be deployed for QoS classes designed to | GSMA IR.34 | DiffServ-Intercon |
transport traffic responding to congestion by traffic reduction. | | |
| 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 |
+---------------+-------+--------------+--------+
The class names of this document follow Y.1566. TCP_optimised and Suggested mapping of GSMA IR.34 classes and PHBs to DiffServ Intercon
especially UDP_optimised are inappropriate class names, as some UDP
based applications are or may be expected to become TCP friendly.
9. Allow for DiffServ extendibility on MPLS and Ethernet level Figure 2
Any aggregated Diffserv deployment faces codepoint depletion issues The motivation resulting in the design of the IR.34 Intercative class
rather soon, if deployed on MPLS or Ethernet. Coding space should be are unknown to the author of this draft. It is out of scope of this
left for new features, like ECN, PCN or Conex. In addition to draft to decide how 4 PHBs can be mapped to a to single aggregated
carrying customer traffic, internal routing and network management class. The suggested mapping is pragmatic and tries to come as close
traffic may be protected by using a separate class. Offering as possible to other design criteria pursued by GSMA IR.34.
interconnection with up to four classes and 4 - 6 MPLS TC's (or
Ethernet P-bits) to that respect is probably at least a fair
compromise.
10. Acknowledgements 5.3. Proposed MEF 23.1 to DiffServ Intercon mapping
David Black gave many helpful comments to this work. Al Morton and MEF 23.1 is an implemenation agreement facilitating Ethernet service
Sebastien Jobert provided feedback on many aspects during private interoperability and consistency between Operators and the use of a
discussions. Brian Carpenter, Mohamed Boucadair and Thomas Knoll common CoS Label set for Subscribers [MEF23.1]. It pursues the same
helped adding awareness of further potentially related work. 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 to 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 network interfaces. MEF
23.1 specifies three aggregated CoS classes. In addition, the usage
of a subset of Ethernet PCP and IP DSCP values is specifiedthus
facilitating synergies between Ethernet and 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.
11. IANA Considerations MEF 23.1 QoS mapping requires some thought as 3 classes are supported
of which two are Ordered Aggregates. MEF 23.1s section 8.5.1 example
on IP DSCP mapping may 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 class. The suggested mapping MEF to DiffServ Intercon is
limited to 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 MEF 23.1 color blind mode classes and PHBs to
DiffServ Intercon
Figure 3
The MEF color aware mode supports Ordered Aggregates in the MEF
classes M and L. The MEF L specification classifies AF1 and Best
Effort for the same Ordered Aggregate. A Better than Best Effort
service produced in the same queue as best effort traffic can 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 the Bulk Inelastic class. Later versions of
this document may do so and specify a solution. Both issues are left
for bilateral negotiation.
6. Contributors
David Black 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 related work.
8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
12. Security Considerations 9. Security Considerations
This document does not introduce new features, it describes how to This document does not introduce new features, it describes how to
use existing ones. The security section of RFC 4597 [RFC4597] use existing ones. The security section of RFC 2475 [RFC2475] and
applies. RFC 4594 [RFC4594] apply.
13. References 10. References
13.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
Access Control Model (VACM) for the Simple Network and W. Weiss, "An Architecture for Differentiated
Management Protocol (SNMP)", RFC 2575, April 1999. Services", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999. "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D. J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002. Behavior)", RFC 3246, March 2002.
[RFC3260] Grossman, D., "New Terminology and Clarifications for [RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002. Diffserv", RFC 3260, April 2002.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, May 2002. 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 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009. Class" Field", RFC 5462, February 2009.
[min_ref] authSurName, authInitials., "Minimal Reference", 2006. [min_ref] authSurName, authInitials., "Minimal Reference", 2006.
13.2. Informative References 10.2. Informative References
[I-D.knoll-idr-cos-interconnect] [I-D.knoll-idr-cos-interconnect]
Knoll, T., "BGP Class of Service Interconnection", Knoll, T., "BGP Class of Service Interconnection",
draft-knoll-idr-cos-interconnect-10 (work in progress), draft-knoll-idr-cos-interconnect-11 (work in progress),
May 2013. November 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 (work in
progress), March 2013.
[ID.idr-sla] [ID.idr-sla]
IETF, "Inter-domain SLA Exchange", IETF, http:// IETF, "Inter-domain SLA Exchange", IETF, http://
datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/, datatracker.ietf.org/doc/draft-ietf-idr-sla-exchange/,
2013. 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 [IR.34] GSMA Association, "IR.34 Inter-Service Provider IP
Backbone Guidelines Version 7.0", GSMA, GSMA IR.34 http:/ Backbone Guidelines Version 7.0", GSMA, GSMA IR.34 http:/
/www.gsma.com/newsroom/wp-content/uploads/2012/03/ /www.gsma.com/newsroom/wp-content/uploads/2012/03/
ir.34.pdf, 2012. ir.34.pdf, 2012.
[MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet [MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet
Class of Service Phase 2", MEF, MEF23.1 http:// Class of Service Phase 2", MEF, MEF23.1 http://
metroethernetforum.org/PDF_Documents/ metroethernetforum.org/PDF_Documents/
technical-specifications/MEF_23.1.pdf, 2012. technical-specifications/MEF_23.1.pdf, 2012.
[RFC4597] Even, R. and N. Ismail, "Conferencing Scenarios", [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
RFC 4597, August 2006. Guidelines for DiffServ Service Classes", RFC 4594,
August 2006.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
Diffserv Service Classes", RFC 5127, February 2008. Diffserv Service Classes", RFC 5127, February 2008.
[RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider- [RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider-
to-Provider Agreements for Internet-Scale Quality of to-Provider Agreements for Internet-Scale Quality of
Service (QoS)", RFC 5160, March 2008. Service (QoS)", RFC 5160, March 2008.
[Y.1566] ITU-T, "Quality of service mapping and interconnection [Y.1566] ITU-T, "Quality of service mapping and interconnection
between Ethernet, IP and multiprotocol label switching between Ethernet, IP and multiprotocol label switching
 End of changes. 69 change blocks. 
381 lines changed or deleted 454 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/