draft-geib-tsvwg-diffserv-intercon-06.txt   draft-geib-tsvwg-diffserv-intercon-07.txt 
TSVWG R. Geib, Ed. TSVWG R. Geib, Ed.
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Intended status: Informational July 4, 2014 Intended status: Informational D. Black
Expires: January 5, 2015 Expires: April 27, 2015 EMC Corporation
October 24, 2014
DiffServ interconnection classes and practice DiffServ interconnection classes and practice
draft-geib-tsvwg-diffserv-intercon-06 draft-geib-tsvwg-diffserv-intercon-07
Abstract Abstract
This document proposes a limited and well defined set of QoS PHBs and This document proposes a limited and well defined set of DiffServ
PHB groups to be applied at (inter)connections of two separately PHBs and codepoints to be applied at (inter)connections of two
administered and operated networks. Many network providers operate separately administered and operated networks. Many network
Treatment Aggregate of different DiffServ classes. This draft offers providers operate MPLS using Treatment Aggregates for traffic marked
a simple and constrained interconnection concept which may simplify with different DiffServ PHBs, and use MPLS for interconnection with
operation and negotiation of DiffServ at interconnection points. other networks. This document offers a simple interconnection
approach that may simplify operation of DiffServ for network
interconnection among providers.
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 January 5, 2015. This Internet-Draft will expire on April 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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. Related work . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Related work . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. MPLS and the Short Pipe tunnel model . . . . . . . . . . . . . 5
3. An Interconnection class and codepoint scheme . . . . . . . . 5 3. An Interconnection class and codepoint scheme . . . . . . . . 6
3.1. Limitations arising from the MPLS Short Pipe model . . . . 9 3.1. End-to-end QoS: PHB and DS CodePoint Transparency . . . . 11
3.2. Treatment of Network Control traffic at carrier 3.2. Treatment of Network Control traffic at carrier
interconnection interfaces . . . . . . . . . . . . . . . . 9 interconnection interfaces . . . . . . . . . . . . . . . . 12
4. DiffServ Intercon relation to other QoS standards 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
(revision may be required) . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
4.1. MPLS, Ethernet and DSCP Precedence Prefixes for 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
aggregated classes . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Proposed GSMA IR.34 to DiffServ Intercon mapping . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
4.3. Proposed MEF 23.1 to DiffServ Intercon mapping . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 15
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
DiffServ has been deployed in many networks. As described by section 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 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 DiffServ feature [RFC2475]. This draft proposes a set of standard
QoS classes and code points at interconnection points to which and QoS classes and code points at interconnection points to which and
from which locally used classes and code points should be mapped. from which locally used classes and code points should be mapped.
Many providers operate MPLS based backbones. RFC 5127 assumes
backbone engineering to ensure that a major link, switch, or router
can fail, and the result will be a routed network that still meets
ambient Service Level Agreements classes(SLAs) [RFC5127]. Based on
it, RFC5127 introduces the concept of Treatment Aggregates, which
allow to forward multiple DSCPs by a single MPLS Traffic Class. This
draft shares the assumption of RFC 5127 on backbone engineering.
RFC3270 adds the Short Pipe Models to the Pipe and Uniform Model
already defined for Differentiated Services and Tunnels [RFC2983] ,
[RFC3270]. It was required due to the presence of Pen-ultimate hop
popping (PHP) of MPLS Labels. RFC3270 expects the Short Pipe model
only to be deployed for IP tunnels and VPNs. If it used to transport
non tunneled IP traffic, some restrictions may apply for DSCP
transparency. The Short Pipe model is popular with many network
providers operating MPLS.
RFC2474 specifies the DiffServ Codepoint Field [RFC2474]. RFC2474 specifies the DiffServ Codepoint Field [RFC2474].
Differentiated treatment is based on the specific DSCP. Once set, it Differentiated treatment is based on the specific DSCP. Once set, it
may change, but any DSCP rewrite is always a one by one mapping. may change. If traffic marked with unknown or unexpected DSCPs is
What is not allowed is remarking n received DSCPs to a single received, RFC2474 recommends forwarding that traffic with default
transmitted DSCP. If unknown DSCPs are received, RFC2474 recommends (best effort) treatment without changing the DSCP markings. Many
transmitting them unchanged by default forwarding. An MPLS network networks do not follow this recommendation, and instead remark
supporting the Short Pipe model for not tunneled IPv4 traffic may unknown or unexpected DSCPs to the zero DSCP for consistency with
need to be able to correctly classify or rewrite the IP DSCP on default (best effort) forwarding.
interfaces between the last Label Switch Router and a Label Edge
Router. In that case, it may not be possible to transmit 64 DSCPs
through this domain.
RFC5127 proposes to transmit DSCPs as they are received in general. Many providers operate MPLS-based backbones that employ backbone
This is not possible, if the receiving and the transmitting domain traffic engineering to ensure that if a major link, switch, or router
use different DSCPs for the PHBs to which traffic is mapped if both fails, the result will be a routed network that continues to meet its
interconnect. Service Level Agreements (SLAs). Based on that foundation,
foundation, [RFC5127] introduces the concept of DiffServ Treatment
Aggregates, which enable traffic marked with multiple DSCPs to be
forwarded in a single MPLS Traffic Class (TC). Like RFC 5127, this
document assumes robust provider backbone traffic engineering.
This draft adresses IP interconnection supporting DiffServ to or RFC5127 recommends transmission of DSCPs as they are received. This
between providers operating MPLS in their backbone. It proposes is not possible, if the receiving and the transmitting domains at a
operational simplifications and methods to match IP DiffServ network interconnection use different DSCPs for the PHBs involved.
requirements with MPLS limitations (especially regarding the Short
Pipe Model if applied for non tunnel IPv4 traffic). The scope of
this draft is limited to 4 specified interconnection Treatment
Aggregates. To ease operation and to ensure traffic to leave a
domain with the DSCPs received, small sets of specific DSCPs and a
definition of their Treatment Aggregate PHB are suggested. The
mechanism proposed here may be extended. This is relevant only if it
sees some deployment, and it is preferred to start with a limited and
simple approach to clarify the concept.
At first glance, the interconnection codepoint scheme may look like This document is motivated by requirements for IP network
an additional effort. But there are some obvious benefits: each interconnection with DiffServ support among providers that operate
party sending or receiving traffic has to specify the mapping from or MPLS in their backbones, but is applicable to other technologies.
to the interconnection class and code point scheme only once. The operational simplifications and methods in this document help
Without it, this is to be negotiated per interconnection party align IP DiffServ functionality with MPLS limitations, particularly
individually. Further, end-to-end QoS in terms of traffic being when MPLS penultimate hop popping is used. That is an important
classified for say, for a sufficiently similar PHB in all passed reason why this document specifies 4 interconnection Treatment
domains is more likely to result if an interconnection code point Aggregates. Limiting DiffServ to a small number Treatment Aggregates
scheme is used. This draft supports a remarking of one DSCP only to can help ensure that network traffic leaves a network with the same
one other DSCPs (no n DSCP to one DSCP remarking). DSCPs that it was received with. The approach proposed here may be
extended by operators or future specifications.
The example given in RFC 5127 on aggregation of DiffServ service In isolation, use of standard interconnection PHBs and DSCPs may
classes picks 4 Treatment Aggregates. This draft also favours 4 appear to be additional effort for a network operator. The primary
Treatment Aggregates. Reasons to favour working with 4 DiffServ offsetting benefit is that the mapping from or to the interconnection
Treatment Aggregates: PHBs and DSCPs is specified once for all of the interconnections to
other networks that can use this approach. Otherwise, the PHBs and
DSCPs have to be negotiated and configured independently for each
network interconnection, which has poor scaling properties. Further,
end-to-end QoS treatment is more likely to result when an
interconnection code point scheme is used because traffic is remarked
to the same PHBs at all network interconnections. This document
supports one-to-one DSCP remarking at network interconnections (not n
DSCP to one DSCP remarking).
o There should be a coding reserve for interconnection classes. The example given in RFC 5127 on aggregation of DiffServ service
This leaves space for future standards, for private bilateral classes uses 4 Treatment Aggregates, and this document does likewise
agreements and for provider internal classes. because:
o The fields available for carrying QoS information (e.g., DiffServ o The available coding space for carrying QoS information (e.g.,
PHB) in MPLS and Ethernet are only 3 bits in size, and are DiffServ PHB) in MPLS and Ethernet is only 3 bits in size, and is
intended for more than just QoS purposes (see e.g. [RFC5129]). intended for more than just QoS purposes (see e.g. [RFC5129]).
o There should be unused codes for interconnection purposes. This
leaves space for future standards, for private bilateral
agreements and for local use PHBs and DSCPs.
o Migrations from one code point scheme to another may require spare o Migrations from one code point scheme to another may require spare
QoS code points. QoS code points.
RFC5127 provides recommendations on aggregation of IP DSCPs into MPLS RFC5127 provides recommendations on aggregation of DSCP-marked
Treatment Aggregates and offers a deployment example [RFC5127]. traffic into MPLS Treatment Aggregates and offers a deployment
RFC5127 seems to be based on an assumption the the MPLS Short Pipe example [RFC5127] that does not work for the MPLS Short Pipe model
model is only deployed for tunneled IP products or VPNs. This draft when that model is used for ordinary network traffic. This document
assumes presence of non tunneled IPv4 traffic and deployment of the supports the MPLS Short Pipe model for ordinary network traffic and
MPLS Short Pipe model. That requires deviating from the RFC5127 hence differs from the RFC5127 approach as follows:
example as follows:
o DSCP remarking is to be expected at provider edges, if the domain o remarking of received DSCPs to domain internal DSCPs is to be
is terminating this traffic. expected for ordinary IP traffic at provider edges (and for outer
headers of tunneled IP traffic).
o This draft follows RFC4594 in the proposed marking of provider o document follows RFC4594 in the proposed marking of provider
Network Control traffic and expands RFC4594 on treatment of CS6 Network Control traffic and expands RFC4594 on treatment of CS6
marked traffic at interconnection points (see section 5.2). marked traffic at interconnection points (see section 3.2).
The proposed Interconnection class and code point scheme tries to This document is organized as follows: section 2 reviews the MPLS
reflect and consolidate related DiffServ and QoS standardisation Short Pipe tunnel model for DiffServ Tunnels [RFC3270]; effective
efforts outside of the IETF, namely MEF [MEF 23.1], GSMA [IR.34] and support for that model is a crucial goal of this document. Section 3
ITU [Y.1566]. GSMAs IR.34 specifies an inter provider VPN, but it is introduces DiffServ interconnection Treatment Aggregates, plus the
nevertheless specifying a kind of DiffServ aware IP based carrier PHBs and DSCPs that are mapped to these Treatment Aggregates.
interconnection. Further, section 3 discusses treatment of non-tunneled and tunneled
IP traffic and MPLS VPN QoS aspects. Finally Network Management PHB
treatment is described. Annex A discusses how domain internal IP
layer QoS schemes impact interconnection. Annex B describes the
impact of the MPLS Short Pipe model (pen ultimate hop popping) on QoS
related IP interconnections.
1.1. Related work 1.1. Related work
In addition to the standardisation activities which triggered this In addition to the activities that triggered this work, there are
work, other authors published RFCs or drafts which may benefit from additional RFCs and Internet-drafts that may benefit from an
an interconnection class- and codepoint scheme. RFC 5160 suggests interconnection PHB and DSCP scheme. RFC 5160 suggests Meta-QoS-
Meta-QoS- Classes to enable deployment of standardised end to end QoS Classes to enable deployment of standardized end to end QoS classes
classes [RFC5160]. The authors agree that the proposed [RFC5160]. In private discussion, the authors of that RFC agree that
interconnection class- and codepoint scheme as well as the idea of the proposed interconnection class- and codepoint scheme and its
standardised end to end classes would complement their own work. enablement of 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. When the basic DiffServ elements for network
be standardised as proposed here, signaled access to QoS classes may interconnection are used as described in this document, signaled
be of interest. The current BGP drafts focus on exchanging SLA and access to QoS classes may be of interest. These two BGP documents
traffic conditioning parameters. They seem to assume that common focus on exchanging SLA and traffic conditioning parameters and
interpretation of the PHB properties identified by DSCPs has been assume that common PHBs identified by the signaled DSCPs have been
established prior to exchanging further details by BGP signaling. established prior to BGP signaling of QoS.
2. Terminology 2. MPLS and the Short Pipe tunnel model
This draft reuses existing terminology of RFCs 2474 and 5127. The Pipe and Uniform models for Differentiated Services and Tunnels
are defined in [RFC2983]. RFC3270 adds the MPLS Short Pipe model in
order to support penultimate hop popping (PHP) of MPLS Labels,
primarily for IP tunnels and VPNs. The Short Pipe model and PHP have
become popular with many network providers that operate MPLS networks
and are now widely used for ordinary network traffic, not just
traffic encapsulated in IP tunnels and VPNs. This has important
implications for DiffServ functionality in MPLS networks.
RFC 2474's recommendation to forward traffic with unrecognized DSCPs
with Default (best effort) service without rewriting the DSCP has
proven to be a poor operational practice. Network operation and
management are simplified when there is a 1-1 match between the DSCP
marked on the packet and the forwarding treatment (PHB) applied by
network nodes. When this is done, CS0 (the all-zero DSCP) is the
only DSCP used for Default forwarding of best effort traffic, so a
common practice is to use CS0 to remark traffic received with
unrecognized or unsupported DSCPs at network edges.
MPLS networks are more subtle in this regard, as it is possible to
encode the provider's DSCP in the MPLS TC field and allow that to
differ from the PHB indicated by the DSCP in the MPLS-encapsulated IP
packet. That would allow an unrecognized DSCP to be carried edge-to-
edge over an MPLS network, because the effective DSCP used by the
MPLS network would be encoded in the MPLS label TC field (and also
carried edge-to-edge); this approach assumes that a provider MPLS
label with the provider's TC field being present at all hops within
the provider's network.
The Short Pipe tunnel model and PHP violate that assumption because
PHP pops and discards the MPLS provider label carrying the provider's
TC field. That discard occurs one hop upstream of the MPLS tunnel
endpoint, resulting in no provider TC info being available at tunnel
egress. Therefore the DSCP field in the MPLS-encapsulated IP header
has to contain a DSCP that is valid for the provider's network;
propagating another DSCP edge-to-edge requires an IP tunnel of some
form. In the absence of IP tunneling (a common case for MPLS
networks), it is not possible to pass all 64 possible DSCP values
edge-to-edge across an MPLS network. See Annex B for a more detailed
discussion.
If transport of a large number (much greater than 4) DSCPs is
required across a network that supports this DiffServ interconnection
scheme, a tunnel or VPN can be provisioned for this purpose, so that
the inner IP header carries the DSCP that is to be preserved not to
be changed. From a network operations perspective, the customer
equipment (CE) is the preferred location for tunnel termination,
although a receiving domains Provider Edge router is another viable
option.
3. An Interconnection class and codepoint scheme 3. An Interconnection class and codepoint scheme
Interconnecting parties face the problem of matching classes to be At an interconnection, the networks involved need to agree on the
interconnected and then to agree on code point mapping. As stated by PHBs used for interconnection and the specific DSCP for each PHB.
the DiffServ Architecture [RFC2475], remarking is a standard This may involve remarking for the interconnection; such remarking is
behaviour at interconnection interfaces. If the MPLS Short Pipe part of the DiffServ Architecture [RFC2475], at least for the network
model is deployed by the receiving domain, the Label Switch Router edge nodes involved in interconnection. See Annex A for a more
prior to and the destination Label Edge Router may have to correctly detailed discussion. This draft proposes a standard interconnection
classify traffic by its DSCP. To avoid DSCPs being misused, only set of 4 Treatment Aggregates with well-defined DSCPs to be
domain internal DSCPs may be tolerated there. This means, that aggregated by them. A sending party remarks DSCPs from internal
traffic terminating within this domain will be delivered with the schemes to the interconnection code points. The receiving party
DSCP matching the properties of the PHB at interconnection, but with remarks DSCPs to her internal scheme. The set of DSCPs and PHBs
the DSCP assigned by the terminating domain. This draft proposes a supported across the two interconnected domains and the treatment of
standard interconnection set of 4 Treatment Aggregates with well PHBs and DSCPs not recognized by the receiving domain should be part
defined DSCPs to be aggregated by them. A sending party remarks of the interconnect SLA.
DSCPs from internal schemes to the Interconnection code points. The
receiving party remarks DSCPs to her internal scheme. The
interconnection code point scheme fully complies with the DiffServ
architecture. DiffServ compliance does not allow for a rewrite of
several received DSCPs with a single DSCP to be transmitted. The set
of DSCPs and PHBs supported accross the two interconnected domains
and the treatment of PHBs and DSCPs not recognised by any of both
domains should be part of an SLA. DiffServ transit to a third party
network is excluded for initial versions of this draft (but may be
added if there's interest).
This draft picks up the DiffServ interconnection class defintions RFC 5127's four treatment aggregates include a Network Control
proposed by ITU-T Y.1566 [Y.1566]. The classes defined there, are aggregate for routing protocols and OAM traffic that is essential for
used as MPLS Treatment Aggregates here. This draft proposes a set of network operation administration, control and management. Using this
Treatment Aggregate PHBs and DSCPs to be aggregated. Their aggregate as one of the four in RFC 5127 implicitly assumes that
properties differ slightly from those of the RFC5127 example: network control traffic is forwarded in potential competition with
all other network traffic, and hence DiffServ must favor such traffic
(e.g., via use of the CS6 codepoint) for network stability. That is
a reasonable assumption for IP-based networks where routing and OAM
protocols are mixed with all other types of network traffic;
corporate networks are an example.
Class Priority: PHB EF, DSCP 101 110. The figures of merit In contrast, mixing of all traffic is not a reasonable assumption for
describing the PHB to be in the range of low single digit MPLS-based provider or carrier networks, where customer traffic is
milliseconds. See [RFC3246]. This class corresponds to RFC usually segregated from network control (routing and OAM) traffic via
5127's real time class, but it is limited to traffic for other means, e.g., network control traffic use of separate LSPs that
which node configuration "ensures that the service rate of EF can be prioritized over customer LSPs (e.g., for VPN service) via
packets on a given output interface exceeds their arrival other means. This sort of of network control traffic from customer
rate at that interface over long and short time intervals" traffic is also used for MPLS-based network interconnections. In
(see RFC 3246). addition, many customers of a network provider do not exchange
Network Control traffic (e.g., routing) with the network provider.
For these reasons, a separate Network Control traffic aggregate is
not important for MPLS-based carrier or provider networks; when such
traffic is not segregated from other traffic, it may reasonably share
the Assured Elastic treatment aggregate (as RFC 5127 suggests for a
situation in which only three treatment aggregates are supported).
Bulk inelastic: The Treatment Aggregate is initially designed only In contrast, VoIP is emerging as a valuable and important class of
to transport PHB AF41, DSCP 100 010 (the other AF4 PHB group network traffic for which network-provided QoS is crucial, as even
PHB's and DSCPs should be reserved for future extension of minor glitches are immediately apparent to the humans involved in the
the set of DSCPs carried by this Treatment Aggregate). conversation.
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 utilising 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 For these reasons, the Diffserv Interconnect scheme in this document
110 is transmitted by this Treatment Aggregate. It may be departs from the approach in RFC 5127 by not providing a Network
optimised to transport traffic without bandwidth Control traffic aggregate, and instead dedicating the fourth traffic
requirements. It aims on very low loss at high bandwidths. aggregate for VoIP traffic. Network Control traffic may still be
Retransmissions after losses characterise the class and exchanged across network interconnections, see Section 3.2 for
influence the buffer design. Active queue management with further discussion.
probabilistic dropping may be deployed. The RFC 5127 example
calls this class Assured Elastic.
Default: The Treatment Aggregate for the default PHB, CS0 with DSCP Similar approaches to use of a small number of traffic aggregates
000 000. This class may be optimised to transport traffic (including recognition of the importance of VoIP traffic) have been
without bandwidth requirements. Retransmissions after losses taken in related standards and recommendations from outside the IETF,
characterise the class and influence the buffer design. e.g., Y.1566 [Y.1566], GSMA IR.34 [IR.34] andMEF23.1 [MEF23.1].
Active queue management with probabilistic dropping may be
deployed. The RFC 5127 example calls this class Elastic.
RFC2474 recommends leaving DSCPs unknown to a receiving domain The list of the four DiffServ Interconnect traffic aggregates
unchanged while default PHB transport is provided. If there's follows, highlighting differences from RFC 5127 and the specific
community interest in this draft, current carrier deployments should traffic classes from RFC 4594 that each class aggregates.
be checked for support of this RFC2474 recommendation.
Telephony Service Treatment Aggregate: PHB EF, DSCP 101 110 and
VOICE-ADMIT, DSCP 101100, see [RFC3246] , [RFC4594][RFC5865].
This Treatment Aggregate corresponds to RFC 5127s real time
Treatment Aggregate definition regarding the queuing, but it
is restricted to transport Telephony Service Class traffic in
the sense of RFC 4594.
Bulk Real-Time Treatment Aggregate: This Treatment Aggregate is
designed to transport PHB AF41, DSCP 100 010 (the other AF4
PHB group PHBs and DSCPs may be used for future extension of
the set of DSCPs carried by this Treatment Aggregate). This
Treatment Aggregate is designed to transport the portions of
RFC 5127's Real Time Treatment Aggregate, which consume large
amounts of bandwidth, namely Broadcast Video, Real-Time
Interactive and Multimedia Conferencing. The treatment
aggregate should be configured with a rate queue (which is in
line with RFC 4594 for the mentioned traffic classes). As
compared to RFC 5127, the number of DSCPs has been reduced to
one (initially) and the proposed queuing mechanism. The
latter is however in line with RFC4594.
Assured Elastic Treatment Aggregate This Treatment Aggregate
consists of the entire AF3 PHB group AF3, i.e., DSCPs 011
010, 011 100 and 011 110. As compared to RFC5127, just the
number of DSCPs, which has been reduced. This document
suggests to transport signaling marked by AF31. RFC5127
suggests to map Network Management traffic into this
Treatment Aggregate, if no separate Network Control Treatment
Aggregate is supported (for a more detailed discussion of
Network Control PHB treatment see section 3.2). GSMA IR.34
proposes to transport signaling traffic by AF31 too.
Default / Elastic Treatment Aggregate: transports the default PHB,
CS0 with DSCP 000 000. RFC 5127 example refers to this
Treatment Aggregate as Aggregate Elastic. An important
difference as compared to RFC5127 is that any traffic with
unrecognized or unsupported DSCPs may be remarked to this
DSCP.
RFC 4594's Multimedia Streaming class has not been mapped to the
above scheme. By the time of writing, the most popular streaming
applications use TCP transport and adapt picture quality in the case
of congestion. These applications are proprietary and still change
behaviour frequently. At this state, the Bulk Real-Time Treatment
Aggregate or the Bulk Real-Time Treatment Aggregate may be a
reasonable match.
The overall approach to DSCP marking at network interconnections is
illustrated by the following example. Provider O and provider W are
peered with provider T. They have agreed upon a QoS interconnection
SLA.
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 Traffic of provider O terminates within provider Ts network, while
the GSMA IR.34 traffic transits through the netwirk of provider T to provider W's traffic transits through the network of provider T to
provider F. Assume all providers to run their own internal codepoint provider F. Assume all providers to run their own internal codepoint
schemes for a class with properties of the DiffServ Intercon Assured schemes for a PHB groupwith properties of the DiffServ Intercon
Treatment Aggregate. See below for a description of GSMA IR.34. Assured Treatment Aggregate.
Provider-O Provider-W Provider-O Provider-W
RFC5127 GSMA 34.1 RFC5127 GSMA 34.1
| | | |
+----------+ +----------+ +----------+ +----------+
|AF21, AF22| |AF31, AF21| |AF21, AF22| | CS3, CS2 |
+----------+ +----------+ +----------+ +----------+
| | | |
V V V V
+++++++++ +++++++++ +++++++++ +++++++++
|Rtr PrO| |Rtr PrW| |Rtr PrO| |Rtr PrW| Rtr Pr:
+++++++++ +++++++++ +++++++++ +++++++++ Router Peering
| DiffServ | | DiffServ |
+----------+ +----------+ +----------+ +----------+
|AF31, AF32| |AF31, AF32| |AF31, AF32| |AF31, AF32|
+----------+ +----------+ +----------+ +----------+
| Intercon | | Intercon |
V V V V
+++++++++ | +++++++++ |
|RtrPrTI|------------------+ |RtrPrTI|------------------+
+++++++++ +++++++++
| Provider-T domain | Provider-T domain
+-----------+ +-----------+
| MPLS TC 2 | | MPLS TC 2 |
| DSCP rew. | | DSCP rew. |
| AF21, AF22| | AF21, AF22|
+-----------+ +-----------+
| | Local DSCPs Provider-T | | Local DSCPs Provider-T
| | +----------+ +++++++++ | | +----------+ +++++++++
V +->|AF21, AF22|->-|RtrDstH| V +->|AF21, AF22|->-|RtrDstH|
| +----------+ +++++++++ | +----------+ +++++++++
+----------+ +----------+ RtrDst:
|AF21, AF22| |AF21, AF22| Router Destination
+----------+ +----------+
| |
+++++++++ +++++++++
|RtrPrTE| |RtrPrTE|
+++++++++ +++++++++
| DiffServ | DiffServ
+----------+ +----------+
|AF31, AF32| |AF31, AF32|
+----------+ +----------+
| Intercon | Intercon
skipping to change at page 8, line 30 skipping to change at page 10, line 4
+----------+ +----------+
| |
+++++++++ +++++++++
|RtrPrTE| |RtrPrTE|
+++++++++ +++++++++
| DiffServ | DiffServ
+----------+ +----------+
|AF31, AF32| |AF31, AF32|
+----------+ +----------+
| Intercon | Intercon
+++++++++ +++++++++
|RtrPrHF| |RtrPrF|
+++++++++ +++++++++
| |
+----------+ +----------+
|AF31, AF21| | CS4, CS3 |
+----------+ +----------+
| |
Provider-F Provider-F
GSM IR.34 GSM IR.34
DiffServ Intercon example DiffServ Intercon example
Figure 1 Figure 1
It is easily visible that all providers only need to deploy internal It is easily visible that all providers only need to deploy internal
DSCP to DiffServ Intercon DSCP mappings to exchange traffic in the DSCP to DiffServ Intercon DSCP mappings to exchange traffic in the
desired classes. desired classes. Provider W has decided that the properties of his
internal classes CS3 and CS2 are best met by the Diffserv Intercon
Assured Elastic Treatment Aggregate, PHBs AF31 and AF32 respectively.
At the outgoing peering interface connecting provider W with provider
T remarks CS3 traffic to AF31 and CS 2 traffic to CS32. The domain
internal PHBs of provider T meeting the Diffserv Intercon Assured
Elastic Treatment Aggregate requirements is AF2. Hence AF31 traffic
received at the interconnection with provider T is remarked to AF21
by the peering router of domain T. As domain T deploys MPLS, further
the MPLS TC ist set to 2. Traffic received with AF32 is remarked to
AF22. The MPLS TC of the Treatment Aggregate is the same, TC 2. At
the pen-ultimate MPLS node, the top MPLS label is removed. The
packet should be forwarded as determined by the incoming MPLS TC.
The peering router connecting domain T with domain F classifies the
packet by it's domain T internal DSCP AF21 for the Diffserv Intercon
Assured Elastic Treatment Aggregate. As it leaves domain T on the
interface to domain F, it is remarked to AF31. The peering router of
domain F classifies the packet for domain F internal PHB CS4, as this
is the PHB with properties matching DiffServ Intercon's Assured
Elastic Treatment Aggregate. Likewise, AF21 traffic is remarked to
AF32 by the peering router od domain T when leaving it and from AF32
to CS3 by domain F's peering router when receiving it.
This example can be extended. Suppose Provider-O also supports a PHB
marked by CS2 and this PHB is supposed to be transported by QoS
within Provider-T domain. Then Provider-O will remark it with a DSCP
other than AF31 DSCP in order to preserve the differentiation from
CS2; AF11 is one possibility that might be private to the
interconnection between Provider-O and Provider-T; there's no
assumption that Provider-W can also use AF11, as it may not be in the
SLA with Provider-W.
Now suppose Provider-W supports CS2 for internal use only. Then no
DiffServ intercon DSCP mapping may be configured at the peering
router. Traffic, sent by Provider-W to Provider-T marked by CS2 due
to a misconfiguration may be remarked to CS0 by Provider-T.
See section 3.1 for further discussion of this and DSCP transparency
in general.
RFC5127 specifies a separate Treatment Aggregate for network control RFC5127 specifies a separate Treatment Aggregate for network control
traffic. It may be present at interconnection interfaces too, but traffic. It may be present at interconnection interfaces too, but
depending on the agreement between providers, Network Control traffic depending on the agreement between providers, Network Control traffic
may also be classified for another interconnection class. See below may also be classified into a different interconnection class. See
for a detailed discussion on the treatment of Network Control section 3.2 for a detailed discussion on the treatment of Network
traffic. Control traffic.
The proposed class and code point scheme is designed for point to RFC2575 states that Ingress nodes must condition all other inbound
point IP layer interconnections. Other types of interconnections are traffic to ensure that the DS codepoints are acceptable; packets
out of scope of this document. The basic class and code point scheme found to have unacceptable codepoints must either be discarded or
is applicable on Ethernet layer too. must have their DS codepoints modified to acceptable values before
being forwarded. For example, an ingress node receiving traffic from
a domain with which no enhanced service agreement exists may reset
the DS codepoint to the Default PHB codepoint. As a consequence, an
interconnect SLA needs to specify not only the treatment of traffic
that arrives with a supported interconnect DSCP, but also the
treatment of traffic that arrives with unsupported or unexpected
DSCPs.
3.1. Limitations arising from the MPLS Short Pipe model The proposed interconnect class and code point scheme is designed for
point to point IP layer interconnections among MPLS networks. Other
types of interconnections are out of scope of this document. The
basic class and code point scheme is applicable on Ethernet layer
too, if a provider e.g. supports Ethernet pririties like specified by
IEEE 802.1p.
If non tunneled IPv4 traffic is transmitted by deploying the MPLS 3.1. End-to-end QoS: PHB and DS CodePoint Transparency
Short Pipe model as specified by RFC3270, then IP DSCPs may be used
for classification or they may be remarked at interfaces between the
destination Label Edge Router and the Label Switch Router. Domain
internal Treatment Aggregates may be applicable, e.g. for domain
internal network control traffic. This Treatment Aggregate and the
DSCPs which are aggregated by it, may not be available for customer
traffic. A domain supporting such an internal Treatment Aggregate
can't support a set of 64 DSCPs in that case. As mentioned below,
the number of PHBs and their DSCPs supported end-to-end should be as
well defined as the treatment of not recognised DSCPs when
negotiating interconnection.
The situation is more relaxed for tunneled IPv4 traffic, IPv6 traffic This section describes how the use of a common PHB and DSCP scheme
in general (for the time being) and for VPN traffic. If there's for interconnection can lead to end-to-end DiffServ-based QoS across
community interest, a later version of this discuss this in more networks that do not have common policies or practices for PHB and
detail. DSCP usage. This will initially be possible for PHBs and DSCPs
corresponding to at most 3 or 4 Treatment Aggregates due to the MPLS
considerations discussed previously.
Networks can be expected to differ in the number of PHBs available at
interconnections (for terminating or transit service) and the DSCP
values used within their domain. At an interconnection, Treatment
Aggregate and PHB properties are best described by SLAs and related
explanatory material. See annex A for a more detailed discussion
about why PHB and g DSCP usage is likely to differ among networks.
For the above reasons and the desire to support interconnection among
networks with different DiffServ schemes, the DiffServ
interconnection scheme supports a small number of PHBs and DSCPs;
this scheme is expandable.
The basic idea is that traffic sent with a DiffServ interconnect PHB
and DSCP is restored to that PHB and DSCP (or a PHB and DSCP within
the AF3 PHB group for the Assured Treatment Aggregate) at each
network interconnection, even though a different PHB and DSCP may be
used by each network involved. So, Bulk Inelastic traffic could be
sent with AF41, remarked to CS3 by the first network and back to AF41
at the interconnection with the second network, which could mark it
to CS5 and back to AF41 at the next interconnection, etc. The result
is end-to-end QoS treatment consistent with the Bulk Inelastic
Traffic Aggregate, and that is signaled or requested by the AF41 DSCP
at each network interconnection in a fashion that allows each network
operator to use their own internal PHB and DSCP scheme.
The key requirement is that the network ingress interconnect DSCP be
restored at network egress, and a key observation is that this is
only feasible in general for a small number of DSCPs.
3.2. Treatment of Network Control traffic at carrier interconnection 3.2. 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, but observes
specification is detailed on domain internal NC traffic and on that network control traffic received at network ingress is generally
traffic exchanged between peering points. Further, it recommends not different from network control traffic within a network that is the
to forward CS6 marked traffic originating from user-controlled end primary use of CS6 envisioned by RFC 4594. A specific example is
points by the NC class of a provider domain. that some CS6 traffic exchanged across carrier interconnections is
terminated at the network ingress node (e.g., if BGP is running
As a minor clarification to RFC4594, "peering" shouldn't be between two routers on opposite ends of an interconnection link),
interpreted in a commercial sense. The NC PHB is applicable also in which is consistent with RFC 4594's recommendation to not use CS6
the case of a purchased network service based on a transit agreement when forwarding CS6-marked traffic originating from user-controlled
with an upstream provider. RFC4594 recommendations on NC traffic are end points.
applicable for IP carrier interconnections in general.
Some CS6 traffic exchanged accross carrier interconnections will The end-to-end QoS discussion in the previous section (3.1) is
terminate at the domain ingress node (e.g., if BGP is running between generally inapplicable to network control traffic - network control
the two routers on opposite ends of the interconnection link). traffic is generally intended to control a network, not be
transported across it. One exception is that network control traffic
makes sense for a purchased transit agreement, and preservation of
CS6 for network control traffic that is transited is reasonable in
some cases. Use of an IP tunnel is suggested in order to reduce the
risk of CS6 markings on transiting network control traffic being
interpreted by the network providing the transit.
If the MPLS Short Pipe model is deployed for non tunneled IPv4 If the MPLS Short Pipe model is deployed for non tunneled IPv4
traffic, an IP carrier may limit access to the NC PHB for traffic traffic, an IP network provider should limit access to the CS6 and
which is recognised as network control traffic relevant to the own CS7 DSCPs so that they are only used for network control traffic for
domain. Interconnecting carriers should specify treatment of CS6 the provider's own network.
marked traffic received at a carrier interconnection which is to be
Interconnecting carriers should specify treatment of CS6 marked
traffic received at a carrier interconnection which is to be
forwarded beyond the ingress node. An SLA covering the following 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 when a provider wishes to send CS6 marked
accross an interconnection link which isn't terminating at the traffic across 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 and marked for both domains. This traffic should be classified and marked for
the NC PHB. 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). As an example GSMA IR.34 proposes an specified by this document). As an example GSMA IR.34 proposes an
Interactive class / AF31 to carry SIP and DIAMETER traffic. While Interactive class / AF31 to carry SIP and DIAMETER traffic. While
this is service control traffic of high importance to the this is service control traffic of high importance to the
interconnected Mobile Network Operators, it is certainly no interconnected Mobile Network Operators, it is certainly no
Network Control traffic for a fixed network providing transit. Network Control traffic for a fixed network providing transit.
The example may not be perfect. It was picked nevertheless The example may not be perfect. It was picked nevertheless
because it refers to an existing standard. 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.
4. DiffServ Intercon relation to other QoS standards (revision may be 4. Acknowledgements
required)
This sections provides suggestions how to aggregate traffic by DSCP
Precedence Prefexies to Ethernet and MPLS. Other Standardisation
Organsiations deal with QoS aware provider interconnection. As IP is
the state of the art realisation of provider interconnections, these
standards bodies specify DiffServ aware interconnections. Some of
these bodies are industry alliances chartered also to promote
interconnection of wireless or Ethernet technology including the
exchange of IP datagrams at interconnection points. Examples are the
Metro Ethernet Forum (MEF) or 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.
4.1. MPLS, Ethernet and DSCP Precedence Prefixes for aggregated classes
The interconnection class and code point scheme respects properties
and limits of a 3 bit PHB coding space in different ways:
o it allows to classify four interconnection classes based on the
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
TC or Ethernet P-Bit mapping functionality. In the opposite, by
limiting the interconnection scheme to 6 PHBs, each PHB may be mapped
to an individual Traffic Class or Priority also within MPLS or
Ethernet (if desired).
4.2. Proposed GSMA IR.34 to DiffServ Intercon mapping
GSMA IR.34 provides guidelines on how to set up and interconnect
Internet Protocol (IP) Packet eXchange (IPX) Networks [IR.34]. An
IPX network is an inter-Service Provider IP backbone which comprises
the interconnected networks of IPX Providers. IPX is a
telecommunications interconnection model for the exchange of IP based
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 not a public
interconnection model however, it is designed as a private IP
Backbone of the interconnected parties. Two IPX partners may
interconnect using transit offered by an Inter-Service Provider IP
Backbone. This requires 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 7 PHBs. Mapping to
DiffServ Intercon is smooth apart from the GSMA aggregated class
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 PHBs to DiffServ Intercon
Figure 2
The motivation resulting in the design of the 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 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.
4.3. Proposed MEF 23.1 to DiffServ Intercon mapping
MEF 23.1 is an implemenation agreement facilitating Ethernet service
interoperability and consistency between Operators and the use of a
common CoS Label set for Subscribers [MEF23.1]. It pursues the same
aims and method on Ethernet layer as this draft does on IP layer
(i.e. providing an interconnection class and codepoint scheme). MEF
23.1 addresses external network 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.
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.
5. Contributors
David Black provided many helpful comments and inputs to this work.
6. Acknowledgements
Al Morton and Sebastien Jobert provided feedback on many aspects Al Morton and Sebastien Jobert provided feedback on many aspects
during private discussions. Mohamed Boucadair and Thomas Knoll during private discussions. Mohamed Boucadair and Thomas Knoll
helped adding awareness of related work. David Black, Fred Baker and helped adding awareness of related work. Fred Baker and Brian
Brian Carpenter provided intensive feedback and discussion. Carpenter provided intensive feedback and discussion.
7. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 6. 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 2475 [RFC2475] and use existing ones. The security section of RFC 2475 [RFC2475] and
RFC 4594 [RFC4594] apply. RFC 4594 [RFC4594] apply.
9. References 7. References
9.1. Normative References 7.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.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
skipping to change at page 15, line 15 skipping to change at page 14, line 50
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 [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, January 2008. 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.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, May 2010.
[min_ref] authSurName, authInitials., "Minimal Reference", 2006. [min_ref] authSurName, authInitials., "Minimal Reference", 2006.
9.2. Informative References 7.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-12 (work in progress), draft-knoll-idr-cos-interconnect-12 (work in progress),
May 2014. May 2014.
[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.
skipping to change at page 16, line 34 skipping to change at page 16, line 25
PHB at interconnection interfaces. Editorial review. PHB at interconnection interfaces. Editorial review.
03 to 04 Again improved terminology. Better wording of Network 03 to 04 Again improved terminology. Better wording of Network
Control PHB at interconnection interfaces. Control PHB at interconnection interfaces.
04 to 05 Large rewrite and re-ordering of contents. 04 to 05 Large rewrite and re-ordering of contents.
05 to 06 Description of IP and MPLS related requirements and 05 to 06 Description of IP and MPLS related requirements and
constraints on DSCP rewrites. constraints on DSCP rewrites.
Author's Address 06 to 07 Largely rewrite, improved match and comparison with RFCs
4594 and 5127.
Authors' Addresses
Ruediger Geib (editor) Ruediger Geib (editor)
Deutsche Telekom Deutsche Telekom
Heinrich Hertz Str. 3-7 Heinrich Hertz Str. 3-7
Darmstadt, 64295 Darmstadt, 64295
Germany Germany
Phone: +49 6151 5812747 Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de Email: Ruediger.Geib@telekom.de
David L. Black
EMC Corporation
176 South Street
Hopkinton, MA
USA
Phone: +1 (508) 293-7953
Email: david.black@emc.com
 End of changes. 61 change blocks. 
413 lines changed or deleted 414 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/