draft-ietf-tsvwg-diffserv-intercon-14.txt   rfc8100.txt 
TSVWG R. Geib, Ed. Internet Engineering Task Force (IETF) R. Geib, Ed.
Internet-Draft Deutsche Telekom Request for Comments: 8100 Deutsche Telekom
Intended status: Informational D. Black Category: Informational D. Black
Expires: June 18, 2017 Dell EMC ISSN: 2070-1721 Dell EMC
December 15, 2016 March 2017
Diffserv-Interconnection classes and practice Diffserv-Interconnection Classes and Practice
draft-ietf-tsvwg-diffserv-intercon-14
Abstract Abstract
This document defines a limited common set of Diffserv Per Hop This document defines a limited common set of Diffserv Per-Hop
Behaviours (PHBs) and codepoints (DSCPs) to be applied at Behaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at
(inter)connections of two separately administered and operated (inter)connections of two separately administered and operated
networks, and explains how this approach can simplify network networks, and it explains how this approach can simplify network
configuration and operation. Many network providers operate Multi configuration and operation. Many network providers operate
Protocol Label Switching (MPLS) using Treatment Aggregates for Multiprotocol Label Switching (MPLS) using Treatment Aggregates for
traffic marked with different Diffserv Per Hop Behaviors, and use traffic marked with different Diffserv Per-Hop Behaviors and use MPLS
MPLS for interconnection with other networks. This document offers a for interconnection with other networks. This document offers a
simple interconnection approach that may simplify operation of simple interconnection approach that may simplify operation of
Diffserv for network interconnection among providers that use MPLS Diffserv for network interconnection among providers that use MPLS
and apply the Short-Pipe tunnel mode. While motivated by the and apply the Short Pipe Model. While motivated by the requirements
requirements of MPLS network operators that use Short-Pipe tunnels, of MPLS network operators that use Short Pipe Model tunnels, this
this document is applicable to other networks, both MPLS and non- document is applicable to other networks, both MPLS and non-MPLS.
MPLS.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on June 18, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8100.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related work . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability Statement . . . . . . . . . . . . . . . . . 4 1.2. Applicability Statement . . . . . . . . . . . . . . . . . 5
1.3. Document Organization . . . . . . . . . . . . . . . . . . 5 1.3. Document Organization . . . . . . . . . . . . . . . . . . 5
2. MPLS and the Short Pipe tunnel model . . . . . . . . . . . . 5 2. MPLS and Short Pipe Model Tunnels . . . . . . . . . . . . . . 6
3. Relationship to RFC5127 . . . . . . . . . . . . . . . . . . . 6 3. Relationship to RFC 5127 . . . . . . . . . . . . . . . . . . 7
3.1. RFC5127 Background . . . . . . . . . . . . . . . . . . . 6 3.1. Background of RFC 5127 . . . . . . . . . . . . . . . . . 7
3.2. Differences from RFC5127 . . . . . . . . . . . . . . . . 7 3.2. Differences from RFC 5127 . . . . . . . . . . . . . . . . 7
4. The Diffserv-Intercon Interconnection Classes . . . . . . . . 8 4. The Diffserv-Intercon Interconnection Classes . . . . . . . . 8
4.1. Diffserv-Intercon Example . . . . . . . . . . . . . . . . 10 4.1. Diffserv-Intercon Example . . . . . . . . . . . . . . . . 11
4.2. End-to-end PHB and DSCP Transparency . . . . . . . . . . 13 4.2. End-to-End PHB and DSCP Transparency . . . . . . . . . . 13
4.3. Treatment of Network Control traffic at carrier 4.3. Treatment of Network Control Traffic at Carrier
interconnection interfaces . . . . . . . . . . . . . . . 14 Interconnection Interfaces . . . . . . . . . . . . . . . 13
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. The MPLS Short Pipe Model and IP Traffic . . . . . . 18
Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic 18 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Diffserv has been deployed in many networks; it provides Diffserv has been deployed in many networks; it provides
differentiated traffic forwarding based on the Diffserv Codepoint differentiated traffic forwarding based on the Diffserv Codepoint
(DSCP) field, which is part of the IP header [RFC2474]. This (DSCP) field, which is part of the IP header [RFC2474]. This
document defines a set of common Diffserv classes (Per Hop Behaviors, document defines a set of common Diffserv classes (Per-Hop Behaviors
PHBs) and code points for use at interconnection points to which and (PHBs)) and codepoints for use at interconnection points to which and
from which locally used classes and code points should be mapped. from which locally used classes and codepoints should be mapped.
As described by section 2.3.4.2 of RFC2475, remarking of packets at As described by Section 2.3.4.2 of [RFC2475], the re-marking of
domain boundaries is a Diffserv feature [RFC2475]. If traffic marked packets at domain boundaries is a Diffserv feature. If traffic
with unknown or unexpected DSCPs is received, RFC2474 recommends marked with unknown or unexpected DSCPs is received, [RFC2474]
forwarding that traffic with default (best effort) treatment without recommends forwarding that traffic with default (best-effort)
changing the DSCP markings to better support incremental Diffserv treatment without changing the DSCP markings to better support
deployment in existing networks as well as with routers that do not incremental Diffserv deployment in existing networks as well as with
support Diffserv or are not configured to support it. Many networks routers that do not support Diffserv or are not configured to support
do not follow this recommendation, and instead remark unknown or it. Many networks do not follow this recommendation and instead
unexpected DSCPs to zero upon receipt for default (best effort) re-mark unknown or unexpected DSCPs to zero upon receipt for default
forwarding in accordance with the guidance in RFC2475 [RFC2475] to (best-effort) forwarding in accordance with the guidance in [RFC2475]
ensure that appropriate DSCPs are used within a Diffserv domain. to ensure that appropriate DSCPs are used within a Diffserv domain.
This draft is based on the latter approach, and defines additional This document is based on the latter approach and defines additional
DSCPs that are known and expected at network interconnection DSCPs that are known and expected at network interconnection
interfaces in order to reduce the amount of traffic whose DSCPs are interfaces in order to reduce the amount of traffic whose DSCPs are
remarked to zero. re-marked to zero.
This document is motivated by requirements for IP network This document is motivated by requirements for IP network
interconnection with Diffserv support among providers that operate interconnection with Diffserv support among providers that operate
Multi Protocol Label Switching (MPLS) in their backbones, but is also Multiprotocol Label Switching (MPLS) in their backbones, but it is
applicable to other technologies. The operational simplifications also applicable to other technologies. The operational
and methods in this document help align IP Diffserv functionality simplifications and methods in this document help align IP Diffserv
with MPLS limitations resulting from the widely deployed Short Pipe functionality with MPLS limitations resulting from the widely
tunnel model for operation [RFC3270]. Further, limiting Diffserv to deployed Short Pipe Model for MPLS tunnel operation [RFC3270].
a small number of Treatment Aggregates can enable network traffic to Further, limiting Diffserv to a small number of Treatment Aggregates
leave a network with the DSCP value with which it was received, even can enable network traffic to leave a network with the DSCP value
if a different DSCP is used within the network, thus providing an with which it was received, even if a different DSCP is used within
opportunity to extend consistent Diffserv treatment across network the network, thus providing an opportunity to extend consistent
boundaries. Diffserv treatment across network boundaries.
In isolation, use of a defined set of interconnection PHBs and DSCPs In isolation, use of a defined set of interconnection PHBs and DSCPs
may appear to be additional effort for a network operator. The may appear to be additional effort for a network operator. The
primary offsetting benefit is that mapping from or to the primary offsetting benefit is that mapping from or to the
interconnection PHBs and DSCPs is specified once for all of the interconnection PHBs and DSCPs is specified once for all of the
interconnections to other networks that can use this approach. interconnections to other networks that can use this approach.
Absent this approach, the PHBs and DSCPs have to be negotiated and Absent this approach, the PHBs and DSCPs have to be negotiated and
configured independently for each network interconnection, which has configured independently for each network interconnection, which has
poor administrative and operational scaling properties. Further, poor administrative and operational scaling properties. Further,
consistent end-to-end Diffserv treatment is more likely to result consistent end-to-end Diffserv treatment is more likely to result
when an interconnection code point scheme is used because traffic is when an interconnection codepoint scheme is used because traffic is
remarked to the same PHBs at all network interconnections. re-marked to the same DSCPs at all network interconnections.
The interconnection approach described in this document (referred to The interconnection approach described in this document (referred to
as Diffserv-Intercon) uses a set of PHBs (mapped to four as "Diffserv-Intercon") uses a set of PHBs (mapped to four
corresponding MPLS treatment aggregates) along with a set of corresponding MPLS Treatment Aggregates) along with a set of
interconnection DSCPs allowing straightforward rewriting to domain- interconnection DSCPs allowing straightforward rewriting to domain-
internal DSCPs and defined DSCP markings for traffic forwarded to internal DSCPs and defined DSCP markings for traffic forwarded to
interconnected domains. The solution described here can be used in interconnected domains. The solution described here can be used in
other contexts benefitting from a defined Diffserv interconnection other contexts benefiting from a defined Diffserv interconnection
interface. interface.
The basic idea is that traffic sent with a Diffserv-Interconnect PHB The basic idea is that traffic sent with a Diffserv-Intercon PHB and
and DSCP is restored to that PHB and DSCP at each network DSCP is restored to that PHB and DSCP at each network
interconnection, even though a different PHB and DSCP may be used by interconnection, even though a different PHB and DSCP may be used
each network involved. The key requirement is that the network within each network involved. The key requirement is that the
ingress interconnect DSCP be restored at network egress, and a key network ingress interconnect DSCP be restored at the network egress,
observation is that this is only feasible in general for a small and a key observation is that this is only feasible in general for a
number of DSCPs. Traffic sent with other DSCPs can be remarked to an small number of DSCPs. Traffic sent with other DSCPs can be
interconnect DSCP or dealt with via additional agreement(s) among the re-marked to an interconnect DSCP or dealt with via an additional
operators of the interconnected networks; use of the MPLS Short Pipe agreement(s) among the operators of the interconnected networks; use
model favors remarking unexpected DSCPs to zero in the absence of of the MPLS Short Pipe Model favors re-marking unexpected DSCPs to
additional agreement(s), as explained further in this document. zero in the absence of an additional agreement(s), as explained
further in this document.
In addition to the common interconnecting PHBs and DSCPs, In addition to the common interconnecting PHBs and DSCPs,
interconnecting operators need to further agree on the tunneling interconnecting operators need to further agree on the tunneling
technology used for interconnection (e.g., MPLS, if used) and control technology used for interconnection (e.g., MPLS, if used) and control
or mitigate the impacts of tunneling on reliability and MTU. or mitigate the impacts of tunneling on reliability and MTU.
1.1. Related work 1.1. Related Work
In addition to the activities that triggered this work, there are In addition to the activities that triggered this work, there are
additional RFCs and Internet-drafts that may benefit from an additional RFCs and Internet-Drafts that may benefit from an
interconnection PHB and DSCP scheme. RFC5160 suggests Meta-QoS- interconnection PHB and DSCP scheme. [RFC5160] suggests
Classes to help enabling deployment of standardized end to end QoS Meta-QoS-Classes to help enable deployment of standardized end-to-end
classes [RFC5160]. The Diffserv-Intercon class- and codepoint scheme QoS classes. The Diffserv-Intercon class and codepoint scheme is
is intended to complement that work (e.g., by enabling a defined set intended to complement that work (e.g., by enabling a defined set of
of interconnection DSCPs and PHBs). interconnection DSCPs and PHBs).
Border Gateway Protocol (BGP) signaling Class of Service at Border Gateway Protocol (BGP) support for signaling Class of Service
interconnection interfaces by BGP [I-D.knoll-idr-cos-interconnect], at interconnection interfaces [BGP-INTERCONNECTION] [SLA-EXCHANGE] is
[ID.ietf-idr-sla] is complementary to Diffserv-Intercon. These two complementary to Diffserv-Intercon. These two BGP documents focus on
BGP documents focus on exchanging Service Level Agreement (SLA) and exchanging Service Level Agreement (SLA) and traffic conditioning
traffic conditioning parameters and assume that common PHBs parameters and assume that common PHBs identified by the signaled
identified by the signaled DSCPs have been established (e.g., via use DSCPs have been established (e.g., via use of the Diffserv-Intercon
of the Diffserv-Intercon DSCPs) prior to BGP signaling of PHB id DSCPs) prior to BGP signaling of PHB id codes.
codes.
1.2. Applicability Statement 1.2. Applicability Statement
This document is applicable to use of Differentiated Services for This document is applicable to the use of Differentiated Services for
interconnection traffic between networks, and is particularly suited interconnection traffic between networks and is particularly suited
to interconnection of MPLS-based networks that use MPLS Short-pipe to interconnection of MPLS-based networks that use MPLS Short Pipe
tunnels. This document is also applicable to other network Model tunnels. This document is also applicable to other network
technologies, but it is not intended for use within an individual technologies, but it is not intended for use within an individual
network, where the approach specified in RFC5127 [RFC5127] is among network, where the approach specified in [RFC5127] is among the
the possible alternatives; see Section 3 for further discussion. possible alternatives; see Section 3 for further discussion.
The Diffserv-Intercon approach described in this document simplifies The Diffserv-Intercon approach described in this document simplifies
IP based interconnection to domains operating the MPLS Short Pipe IP-based interconnection to domains operating the MPLS Short Pipe
model for IP traffic, both terminating within the domain and Model for IP traffic, both terminating within the domain and
transiting onward to another domain. Transiting traffic is received transiting onward to another domain. Transiting traffic is received
and sent with the same PHB and DSCP. Terminating traffic maintains and sent with the same PHB and DSCP. Terminating traffic maintains
the PHB with which it was received, however the DSCP may change. the PHB with which it was received; however, the DSCP may change.
Diffserv-Intercon is also applicable to the Pipe tunneling model Diffserv-Intercon is also applicable to Pipe Model tunneling
[RFC2983], [RFC3270], but it is not applicable to the Uniform [RFC2983] [RFC3270], but it is not applicable to Uniform Model
tunneling model [RFC2983], [RFC3270]. tunneling [RFC2983] [RFC3270].
The Diffserv-Intercon approach defines a set of four PHBs for support The Diffserv-Intercon approach defines a set of four PHBs for support
at interconnections (or network boundaries in general). at interconnections (or network boundaries in general).
Corresponding DSCPs for use at an interconnection interface are Corresponding DSCPs for use at an interconnection interface are also
added. Diffserv-intercon allows for a simple mapping of PHBs and defined. Diffserv-Intercon allows for a simple mapping of PHBs and
DSCPs to MPLS Treatment Aggregates. It is extensible by IETF DSCPs to MPLS Treatment Aggregates. It is extensible by IETF
standardisation and this allows additional PHBs and DSCPs to be standardization, and this allows additional PHBs and DSCPs to be
specified for the Diffserv-intercon scheme. Coding space for private specified for the Diffserv-Intercon scheme. Coding space for private
interconnection agreements or provider internal services is left too. interconnection agreements or provider internal services is
available, as only a single digit number of standard DSCPs are
applied by the Diffserv-Intercon approach.
1.3. Document Organization 1.3. Document Organization
This document is organized as follows: section 2 reviews the MPLS This document is organized as follows: Section 2 reviews the MPLS
Short Pipe tunnel model for Diffserv Tunnels [RFC3270], because Short Pipe Model for Diffserv Tunnels [RFC3270], because effective
effective support for that model is a crucial goal of Diffserv- support for that model is a crucial goal of Diffserv-Intercon.
Intercon. Section 3 provides background on RFC5127's approach to Section 3 provides background on the approach described in RFC 5127
traffic class aggregation within a Diffserv network domain and to Traffic Class (TC) aggregation within a Diffserv network domain
contrasts it with the Diffserv-Intercon approach. Section 4 and contrasts it with the Diffserv-Intercon approach. Section 4
introduces Diffserv-Interconnection Treatment Aggregates, along with introduces Diffserv-Intercon Treatment Aggregates, along with the
the PHBs and DSCPs that they use, and explains how other PHBs (and PHBs and DSCPs that they use, and explains how other PHBs (and
associated DSCPs) may be mapped to these Treatment Aggregates. associated DSCPs) may be mapped to these Treatment Aggregates.
Section 4 also discusses treatment of IP traffic, MPLS VPN Diffserv Section 4 also discusses treatment of IP traffic, MPLS VPN Diffserv
considerations and handling of high-priority Network Management considerations, and the handling of high-priority network management
traffic. Appendix A describes how the MPLS Short Pipe model traffic. Appendix A describes how the MPLS Short Pipe Model
(penultimate hop popping) impacts DSCP marking for IP (Penultimate Hop Popping (PHP)) impacts DSCP marking for IP
interconnections. interconnections.
2. MPLS and the Short Pipe tunnel model 2. MPLS and Short Pipe Model Tunnels
This section provides a summary of the implications of the MPLS Short This section provides a summary of the implications of MPLS Short
Pipe tunnels, and in particular their use of Penultimate Hop Popping Pipe Model tunnels and, in particular, their use of PHP (see RFC
(PHP, see RFC3270) on the Diffserv tunnel framework described in 3270) on the Diffserv tunnel framework described in RFC 2983. The
RFC2983. The Pipe and Uniform models for Differentiated Services and Pipe and Uniform Models for Differentiated Services and Tunnels are
Tunnels are defined in [RFC2983]. RFC3270 adds the Short Pipe model defined in [RFC2983]. RFC 3270 adds the Short Pipe Model to reflect
to reflect the impact of MPLS PHP, primarily for MPLS-based IP the impact of MPLS PHP, primarily for MPLS-based IP tunnels and VPNs.
tunnels and VPNs. The Short Pipe model and PHP have subsequently The Short Pipe Model and PHP have subsequently become popular with
become popular with network providers that operate MPLS networks and network providers that operate MPLS networks and are now widely used
are now widely used to transport unencapsulated IP traffic. This has to transport unencapsulated IP traffic. This has important
important implications for Diffserv functionality in MPLS networks. implications for Diffserv functionality in MPLS networks.
RFC2474's recommendation to forward traffic with unrecognized DSCPs Per RFC 2474, the recommendation to forward traffic with unrecognized
with Default (best effort) service without rewriting the DSCP has not DSCPs with default (best-effort) service without rewriting the DSCP
been widely deployed in practice. Network operation and management has not been widely deployed in practice. Network operation and
are simplified when there is a 1-1 match between the DSCP marked on management are simplified when there is a 1-1 match between the DSCP
the packet and the forwarding treatment (PHB) applied by network marked on the packet and the forwarding treatment (PHB) applied by
nodes. When this is done, CS0 (the all-zero DSCP) is the only DSCP network nodes. When this is done, CS0 (the all-zero DSCP) is the
used for Default forwarding of best effort traffic, and a common only DSCP used for default forwarding of best-effort traffic, and a
practice is to remark to CS0 any traffic received with unrecognized common practice is to re-mark to CS0 any traffic received with
or unsupported DSCPs at network edges. unrecognized or unsupported DSCPs at network edges.
MPLS networks are more subtle in this regard, as it is possible to MPLS networks are more subtle in this regard, as it is possible to
encode the provider's DSCP in the MPLS Traffic Class (TC) field and encode the provider's DSCP in the MPLS TC field and allow that to
allow that to differ from the PHB indicated by the DSCP in the MPLS- differ from the PHB indicated by the DSCP in the MPLS-encapsulated IP
encapsulated IP packet. If the MPLS label with the provider's TC packet. If the MPLS label with the provider's TC field is present at
field is present at all hops within the provider network, this all hops within the provider network, this approach would allow an
approach would allow an unrecognized DSCP to be carried edge-to-edge unrecognized DSCP to be carried edge-to-edge over an MPLS network,
over an MPLS network, because the effective DSCP used by the because the effective DSCP used by the provider's MPLS network would
provider's MPLS network would be encoded in the MPLS label TC field be encoded in the MPLS label TC field (and also carried
(and also carried edge-to-edge). Unfortunately this is only true for edge-to-edge). Unfortunately, this is only true for Pipe Model
the Pipe tunnel model. tunnels.
The Short Pipe tunnel model and PHP behave differently because PHP Short Pipe Model tunnels and PHP behave differently because PHP
removes and discards the MPLS provider label carrying the provider's removes and discards the MPLS provider label carrying the provider's
TC field before the traffic exits the provider's network. That TC field before the traffic exits the provider's network. That
discard occurs one hop upstream of the MPLS tunnel endpoint (which is discard occurs one hop upstream of the MPLS tunnel endpoint (which is
usually at the network edge), resulting in no provider TC info being usually at the network edge), resulting in no provider TC information
available at tunnel egress. To ensure consistent handling of traffic being available at the tunnel egress. To ensure consistent handling
at the tunnel egress, the DSCP field in the MPLS-encapsulated IP of traffic at the tunnel egress, the DSCP field in the MPLS-
header has to contain a DSCP that is valid for the provider's encapsulated IP header has to contain a DSCP that is valid for the
network, so that IP header cannot be used to carry a different DSCP provider's network, so that the IP header cannot be used to carry a
edge-to-edge. See Appendix A for a more detailed discussion. different DSCP edge-to-edge. See Appendix A for a more detailed
discussion.
3. Relationship to RFC5127 3. Relationship to RFC 5127
This document draws heavily upon RFC5127's approach to aggregation of This document draws heavily upon the approach to aggregation of
Diffserv traffic classes for use within a network, but there are Diffserv TCs for use within a network as described in RFC 5127, but
important differences caused by characteristics of network there are important differences caused by characteristics of network
interconnects that differ from links within a network. interconnects that differ from links within a network.
3.1. RFC5127 Background 3.1. Background of RFC 5127
Many providers operate MPLS-based backbones that employ backbone Many providers operate MPLS-based backbones that employ backbone
traffic engineering to ensure that if a major link, switch, or router traffic engineering to ensure that if a major link, switch, or router
fails, the result will be a routed network that continues to fails, the result will be a routed network that continues to
function. Based on that foundation, [RFC5127] introduced the concept function. Based on that foundation, [RFC5127] introduced the concept
of Diffserv Treatment Aggregates, which enable traffic marked with of Diffserv Treatment Aggregates, which enable traffic marked with
multiple DSCPs to be forwarded in a single MPLS Traffic Class (TC) multiple DSCPs to be forwarded in a single MPLS TC based on robust
based on robust provider backbone traffic engineering. This enables provider backbone traffic engineering. This enables differentiated
differentiated forwarding behaviors within a domain in a fashion that forwarding behaviors within a domain in a fashion that does not
does not consume a large number of MPLS Traffic Classes. consume a large number of MPLS TCs.
RFC5127 provides an example aggregation of Diffserv service classes RFC 5127 provides an example aggregation of Diffserv service classes
into 4 Treatment Aggregates. A small number of aggregates are used into four Treatment Aggregates. A small number of aggregates are
because: used because:
o The available coding space for carrying Traffic Class information o The available coding space for carrying TC information (e.g.,
(e.g., Diffserv PHB) in MPLS (and Ethernet) is only 3 bits in Diffserv PHB) in MPLS (and Ethernet) is only 3 bits in size and is
size, and is intended for more than just Diffserv purposes (see, intended for more than just Diffserv purposes (see, e.g.,
e.g., [RFC5129]). [RFC5129]).
o The common interconnection DSCPs ought not to use all 8 possible o The common interconnection DSCPs ought not to use all 8 possible
values. This leaves space for future standards, for private values. This leaves space for future standards, private bilateral
bilateral agreements and for local use PHBs and DSCPs. agreements, and local use PHBs and DSCPs.
o Migrations from one Diffserv code point scheme to a different one o Migrations from one DSCP scheme to a different one is another
is another possible application of otherwise unused DSCPs. possible application of otherwise unused DSCPs.
3.2. Differences from RFC5127 3.2. Differences from RFC 5127
Like RFC5127, this document also uses four traffic aggregates, but Like RFC 5127, this document also uses four Treatment Aggregates, but
differs from RFC5127 in some important ways: it differs from RFC 5127 in some important ways:
o It follows RFC2475 in allowing the DSCPs used within a network to o It follows RFC 2475 in allowing the DSCPs used within a network to
differ from those to exchange traffic with other networks (at differ from those used to exchange traffic with other networks (at
network edges), but provides support to restore ingress DSCP network edges), but it provides support to restore ingress DSCP
values if one of the recommended interconnect DSCPs in this draft values if one of the recommended interconnect DSCPs in this
is used. This results in DSCP remarking at both network ingress document is used. This results in DSCP re-marking at both network
and network egress, and this draft assumes that such remarking at ingress and network egress, and this document assumes that such
network edges is possible for all interface types. re-marking at network edges is possible for all interface types.
o Diffserv-Intercon suggests limiting the number of interconnection o Diffserv-Intercon suggests limiting the number of interconnection
PHBs per Treatment Aggregate to the minimum required. As further PHBs per Treatment Aggregate to the minimum required. As further
discussed below, the number of PHBs per Treatment Aggregate is no discussed below, the number of PHBs per Treatment Aggregate is no
more than two. When two PHBs are specified for a Diffserv- more than two. When two PHBs are specified for a Diffserv-
Intercon treatment aggregate, the expectation is that the provider Intercon Treatment Aggregate, the expectation is that the provider
network supports DSCPs for both PHBs, but uses a single MPLS TC network supports DSCPs for both PHBs but uses a single MPLS TC for
for the Treatment Aggregate that contains the two PHBs. the Treatment Aggregate that contains the two PHBs.
o Diffserv-Intercon suggests mapping other PHBs and DSCPs into the o Diffserv-Intercon suggests mapping other PHBs and DSCPs into the
interconnection Treatment Aggregates as further discussed below. interconnection Treatment Aggregates as further discussed below.
o Diffserv-Intercon treats network control traffic as a special o Diffserv-Intercon treats network control (NC) traffic as a special
case. Within a provider's network, the CS6 DSCP is used for local case. Within a provider's network, the CS6 DSCP is used for local
network control traffic (routing protocols and Operations, network control traffic (routing protocols and Operations,
Administration, and Maintenance (OAM) traffic that is essential to Administration, and Maintenance (OAM) traffic that is essential to
network operation administration, control and management) that may network operation administration, control, and management) that
be destined for any node within the network. In contrast, network may be destined for any node within the network. In contrast,
control traffic exchanged between networks (e.g., BGP) usually network control traffic exchanged between networks (e.g., BGP)
terminates at or close to a network edge, and is not forwarded usually terminates at or close to a network edge and is not
through the network because it is not part of internal routing or forwarded through the network because it is not part of internal
OAM for the receiving network. In addition, such traffic is routing or OAM for the receiving network. In addition, such
unlikely to be covered by standard interconnection agreements; traffic is unlikely to be covered by standard interconnection
rather, it is more likely to be specifically configured (e.g., agreements; rather, it is more likely to be specifically
most networks impose restrictions on use of BGP with other configured (e.g., most networks impose restrictions on use of BGP
networks for obvious reasons). See Section 4.2 for further with other networks for obvious reasons). See Section 4.2 for
discussion. further discussion.
o Because RFC5127 used a Treatment Aggregate for network control o Because RFC 5127 used a Treatment Aggregate for network control
traffic, Diffserv-Intercon can instead define a fourth traffic traffic, Diffserv-Intercon can instead define a fourth Treatment
aggregate to be defined for use at network interconnections Aggregate for use at network interconnections instead of the
instead of the Network Control aggregate in RFC5127. Network Network Control Treatment Aggregate in RFC 5127. Network control
Control traffic may still be exchanged across network traffic may still be exchanged across network interconnections as
interconnections as further discussed in Section 4.2. Diffserv- further discussed in Section 4.2. Diffserv-Intercon uses this
Intercon uses this fourth traffic aggregate for VoIP traffic, fourth Treatment Aggregate for Voice over IP (VoIP) traffic, where
where network-provided service differentiation is crucial, as even network-provided service differentiation is crucial, as even minor
minor glitches are immediately apparent to the humans involved in glitches are immediately apparent to the humans involved in the
the conversation. conversation.
4. The Diffserv-Intercon Interconnection Classes 4. The Diffserv-Intercon Interconnection Classes
At an interconnection, the networks involved need to agree on the At an interconnection, the networks involved need to agree on the
PHBs used for interconnection and the specific DSCP for each PHB. PHBs used for interconnection and the specific DSCP for each PHB.
This document defines a set of 4 interconnection Treatment Aggregates This document defines a set of four interconnection Treatment
with well-defined DSCPs to be aggregated by them. A sending party Aggregates with well-defined DSCPs to be aggregated by them. A
remarks DSCPs from internal schemes to the interconnection code sending party re-marks DSCPs from internal usage to the
points. The receiving party remarks DSCPs to their internal scheme. interconnection codepoints. The receiving party re-marks DSCPs to
The interconnect SLA defines the set of DSCPs and PHBs supported their internal usage. The interconnect SLA defines the set of DSCPs
across the two interconnected domains and the treatment of PHBs and and PHBs supported across the two interconnected domains and the
DSCPs that are not recognized by the receiving domain. treatment of PHBs and DSCPs that are not recognized by the receiving
domain.
Similar approaches that use a small number of traffic aggregates Similar approaches that use a small number of Treatment Aggregates
(including recognition of the importance of VoIP traffic) have been (including recognition of the importance of VoIP traffic) have been
taken in related standards and recommendations from outside the IETF, taken in related standards and recommendations from outside the IETF,
e.g., Y.1566 [Y.1566], GSMA IR.34 [IR.34]and MEF23.1 [MEF23.1]. e.g., Y.1566 [Y.1566], Global System for Mobile Communications
Association (GSMA) IR.34 [IR.34], and MEF23.1 [MEF23.1].
The list of the four Diffserv-Interconnect traffic aggregates The list of the four Diffserv-Intercon Treatment Aggregates follows,
follows, highlighting differences from RFC5127 and suggesting highlighting differences from RFC 5127 and suggesting mappings for
mappings for all RFC4594 traffic classes to Diffserv-Intercon all RFC 4594 TCs to Diffserv-Intercon Treatment Aggregates:
Treatment Aggregates:
Telephony Service Treatment Aggregate: PHB EF, DSCP 101 110 and PHB Telephony Service Treatment Aggregate: PHB Expedited Forwarding
VOICE-ADMIT, DSCP 101 100, see [RFC3246], [RFC4594] and (EF), DSCP 101 110 and PHB VOICE-ADMIT, DSCP 101 100 (see
[RFC5865]. This Treatment Aggregate corresponds to RFC5127's [RFC3246], [RFC4594], and [RFC5865]). This Treatment
real time Treatment Aggregate definition regarding the Aggregate corresponds to the Real-Time Treatment Aggregate
queuing (both delay and jitter should be minimized), but this definition regarding the queuing (both delay and jitter
aggregate is restricted to transport Telephony Service Class should be minimized) per RFC 5127, but this aggregate is
traffic in the sense of RFC4594 [RFC4594]. restricted to transport Telephony service class traffic in
the sense of [RFC4594].
Bulk Real-Time Treatment Aggregate: This Treatment Aggregate is Bulk Real-Time Treatment Aggregate: This Treatment Aggregate is
designed to transport PHB AF41, DSCP 100 010 (the other AF4 designed to transport PHB AF41, DSCP 100 010 (the other AF4
PHB group PHBs and DSCPs may be used for future extension of PHB group PHBs and DSCPs may be used for future extension of
the set of DSCPs carried by this Treatment Aggregate). This the set of DSCPs carried by this Treatment Aggregate). This
Treatment Aggregate is intended for Diffserv-Intercon network Treatment Aggregate is intended to provide Diffserv-Intercon
interconnection of the portions of RFC5127's Real Time network interconnection of a subset of the Real-Time
Treatment Aggregate, that consume significant bandwidth. Treatment Aggregate defined in RFC 5127, specifically the
This traffic is expected to consist of the RFC4594 classes portions that consume significant bandwidth. This traffic is
Broadcast Video, Real-Time Interactive and Multimedia expected to consist of the following classes defined in RFC
Conferencing. This treatment aggregate should be configured 4594: Broadcast Video, Real-Time Interactive, and Multimedia
with a rate queue (consistent with RFC4594's recommendation Conferencing. This Treatment Aggregate should be configured
for the transported traffic classes). By comparison to with a rate-based queue (consistent with the recommendation
RFC5127, the number of DSCPs has been reduced to one for the transported TCs in RFC 4594). By comparison to RFC
5127, the number of DSCPs has been reduced to one
(initially). The AF42 and AF43 PHBs could be added if there (initially). The AF42 and AF43 PHBs could be added if there
is a need for three-color marked Multimedia Conferencing is a need for three-color marked Multimedia Conferencing
traffic. traffic.
Assured Elastic Treatment Aggregate This Treatment Aggregate Assured Elastic Treatment Aggregate: This Treatment Aggregate
consists of PHBs AF31 and AF32 ( i.e., DSCPs 011 010 and 011 consists of PHBs AF31 and AF32 (i.e., DSCPs 011 010 and 011
100). By comparison to RFC5127, the number of DSCPs has been 100). By comparison to RFC 5127, the number of DSCPs has
reduced to two. This document suggests to transport been reduced to two. This document suggests to transport
signaling marked by AF31 (e.g., as recommended by GSMA IR.34 signaling marked by AF31 (e.g., as recommended by GSMA IR.34
[IR.34]). AF33 is reserved for extension of PHBs to be [IR.34]). AF33 is reserved for the extension of PHBs to be
aggregated by this TA. For Diffserv-Intercon network aggregated by this Treatment Aggregate. For Diffserv-
interconnection, the following RFC4594 service classes should Intercon network interconnection, the following service
be mapped to the Assured Elastic Treatment Aggregate: the classes (per RFC 4594) should be mapped to the Assured
Signaling Service Class (being marked for lowest loss Elastic Treatment Aggregate: the Signaling service class
probability), Multimedia Streaming Service Class, the Low- (being marked for lowest loss probability), the Multimedia
Latency Data Service Class and the High-Throughput Data Streaming service class, the Low-Latency Data service class,
Service Class. and the High-Throughput Data service class.
Default / Elastic Treatment Aggregate: transports the default PHB, Default / Elastic Treatment Aggregate: Transports the Default PHB,
CS0 with DSCP 000 000. RFC5127 example refers to this CS0 with DSCP 000 000. An example in RFC 5127 refers to this
Treatment Aggregate as Aggregate Elastic. An important Treatment Aggregate as "Elastic Treatment Aggregate". An
difference from RFC5127 is that any traffic with unrecognized important difference from RFC 5127 is that any traffic with
or unsupported DSCPs may be remarked to this DSCP. For unrecognized or unsupported DSCPs may be re-marked to this
Diffserv-Intercon network interconnection, the RFC4594 DSCP. For Diffserv-Intercon network interconnection, the
standard service class and Low-priority Data service class Standard service class and Low-Priority Data service class
should be mapped to this Treatment Aggregate. This document defined in RFC 4594 should be mapped to this Treatment
does not specify an interconnection class for RFC4594 Low- Aggregate. This document does not specify an interconnection
priority data. This data may be forwarded by a Lower Effort class for Low-Priority Data (also defined RFC 4594). This
PHB in one domain (like the PHB proposed by Informational traffic may be forwarded with a Lower Effort PHB in one
[RFC3662]), but using the methods specified in this document domain (e.g., the PHB proposed by Informational [RFC3662]),
will be remarked with DSCP CS0 at a Diffserv-Intercon network but the methods specified in this document re-mark this
interconnection. This has the effect that Low-priority data traffic with DSCP CS0 at a Diffserv-Intercon network
is treated the same as data sent using the default class. interconnection. This has the effect that Low-Priority Data
(Note: In a network that implements RFC2474, Low-priority is treated the same as data sent using the Standard service
traffic marked as CS1 would otherwise receive better class. (Note: In a network that implements RFC 2474, Low-
treatment than traffic using the default class.) Priority traffic marked as CS1 would otherwise receive better
treatment than Standard traffic using the default PHB.)
RFC2475 states that Ingress nodes must condition all inbound traffic RFC 2475 states that ingress nodes must condition all inbound traffic
to ensure that the DS codepoints are acceptable; packets found to to ensure that the DS codepoints are acceptable; packets found to
have unacceptable codepoints must either be discarded or must have have unacceptable codepoints must either be discarded or have their
their DS codepoints modified to acceptable values before being DS codepoints modified to acceptable values before being forwarded.
forwarded. For example, an ingress node receiving traffic from a For example, an ingress node receiving traffic from a domain with
domain with which no enhanced service agreement exists may reset the which no enhanced service agreement exists may reset the DS codepoint
DS codepoint to CS0. As a consequence, an interconnect SLA needs to to CS0. As a consequence, an interconnect SLA needs to specify not
specify not only the treatment of traffic that arrives with a only the treatment of traffic that arrives with a supported
supported interconnect DSCP, but also the treatment of traffic that interconnect DSCP but also the treatment of traffic that arrives with
arrives with unsupported or unexpected DSCPs; remarking to CS0 is a unsupported or unexpected DSCPs; re-marking to CS0 is a widely
widely deployed behavior. deployed behavior.
During the process of setting up a Diffserv interconnection, both During the process of setting up a Diffserv interconnection, both
networks should define the set of acceptable and unacceptable DSCPs networks should define the set of acceptable and unacceptable DSCPs
and specify the treatment of traffic marked with each DSCP. and specify the treatment of traffic marked with each DSCP.
While Diffserv-Intercon allows modification of unacceptable DSCPs, if While Diffserv-Intercon allows modification of unacceptable DSCPs, if
traffic using one or more of the PHBs in a PHB group (e.g., AF3x, traffic using one or more of the PHBs in a PHB group (e.g., AF3x,
consisting of AF31, AF32 and AF33) is accepted as part of a supported consisting of AF31, AF32, and AF33) is accepted as part of a
Diffserv-Intercon Treatment Aggregate, then traffic using other PHBs supported Diffserv-Intercon Treatment Aggregate, then traffic using
from the same PHB group should not be modified to use PHBs outside of other PHBs from the same PHB group should not be modified to use PHBs
that PHB group, and in particular should not be remarked to CS0 outside of that PHB group and, in particular, should not be re-marked
unless the entire PHB group is remarked to CS0. This avoids to CS0 unless the entire PHB group is re-marked to CS0. This avoids
unexpected forwarding behavior (and potential reordering, see also unexpected forwarding behavior (and potential reordering; see also
[RFC7657]) when using Assured Forwarding (AF) PHBs [RFC2597]. [RFC7657]) when using Assured Forwarding (AF) PHBs [RFC2597].
4.1. Diffserv-Intercon Example 4.1. Diffserv-Intercon Example
The overall approach to DSCP marking at network interconnections is The overall approach to DSCP marking at network interconnections is
illustrated by the following example. Provider O and provider W are illustrated by the following example. Provider O, provider W, and
peered with provider T. They have agreed upon a Diffserv provider F are peered with provider T. They have agreed upon a
interconnection SLA. Diffserv interconnection SLA.
Traffic of provider O terminates within provider T's network, while Traffic of provider O terminates within provider T's network, while
provider W's traffic transits through the network of provider T to provider W's traffic transits through the network of provider T to
provider F. This example assumes that all providers use their own provider F. This example assumes that all providers use their own
internal PHB and codepoint (DSCP) that correspond to the AF31 PHB in internal PHB and codepoint (DSCP) that correspond to the AF31 PHB in
the Diffserv-Intercon Assured Elastic Treatment Aggregate (AF21 and the Diffserv-Intercon Assured Elastic Treatment Aggregate (AF21, CS2,
CS2 are used in the example). and AF11 are used in the example).
Provider O Provider W Provider O Provider W
| | | |
+----------+ +----------+ +----------+ +----------+
| AF21 | | CS2 | | AF21 | | CS2 |
+----------+ +----------+ +----------+ +----------+
V V V V
+~~~~~~~+ +~~~~~~~+ +~~~~~~~+ +~~~~~~~+
|Rtr PrO| |Rtr PrW| Rtr: Router |Rtr PrO| |Rtr PrW| Rtr: Router
+~~~~~~~+ +~~~~~~~+ Pr[L]: Provider[L] +~~~~~~~+ +~~~~~~~+ Pr[L]: Provider[L]
| DiffServ | | Diffserv |
+----------+ +----------+ +----------+ +----------+
| AF31 | | AF31 | | AF31 | | AF31 |
+----------+ +----------+ +----------+ +----------+
V Intercon V V Intercon V
+~~~~~~~+ | +~~~~~~~+ |
|RtrPrTI|------------------+ Router Provider T Ingress |RtrPrTI|------------------+ Router Provider T Ingress
+~~~~~~~+ +~~~~~~~+
| Provider T domain | Provider T Domain
+------------------+ +------------------+
| MPLS TC 2, AF21 | | MPLS TC 2, AF21 |
+------------------+ +------------------+
| | +----------+ +~~~~~~~+ | | +----------+ +~~~~~~~+
V `--->| AF21 |->-|RtrDstH| Router Destination Host V `--->| AF21 |->-|RtrDstH| Router Destination Host
+----------+ +----------+ +~~~~~~~+ +----------+ +----------+ +~~~~~~~+
| AF21 | Local DSCPs Provider T | AF21 | Local DSCPs Provider T
+----------+ +----------+
| |
+~~~~~~~+ +~~~~~~~+
|RtrPrTE| Router Provider T Egress |RtrPrTE| Router Provider T Egress
+~~~~~~~+ +~~~~~~~+
| DiffServ | Diffserv
+----------+ +----------+
| AF31 | | AF31 |
+----------+ +----------+
| Intercon | Intercon
+~~~~~~~+ +~~~~~~~+
|RtrPrF | Router Provider F |RtrPrF | Router Provider F
+~~~~~~~+ +~~~~~~~+
| |
+----------+ +----------+
| AF11 | Provider F | AF11 | Provider F
+----------+ +----------+
Diffserv-Intercon example Figure 1: Diffserv-Intercon Example
Figure 1
Providers only need to deploy mappings of internal DSCPs to/from Providers only need to deploy mappings of internal DSCPs to/from
Diffserv-Intercon DSCPs so that they can exchange traffic using the Diffserv-Intercon DSCPs, so that they can exchange traffic using the
desired PHBs. In the example, provider O has decided that the desired PHBs. In the example, provider O has decided that the
properties of his internal class AF21 are best met by the Diffserv- properties of his internal class AF21 are best met by the Diffserv-
Intercon Assured Elastic Treatment Aggregate, PHB AF31. At the Intercon Assured Elastic Treatment Aggregate, PHB AF31. At the
outgoing peering interface connecting provider O with provider T the outgoing peering interface connecting provider O with provider T, the
former's peering router remarks AF21 traffic to AF31. The domain former's peering router re-marks AF21 traffic to AF31. The domain
internal PHB of provider T meeting the requirement of Diffserv- internal PHB of provider T that meets the requirement of the
Intercon Assured Elastic Treatment Aggregate are from AF2x PHB group. Diffserv-Intercon Assured Elastic Treatment Aggregate is from the
Hence AF31 traffic received at the interconnection with provider T is AF2x PHB group. Hence, AF31 traffic received at the interconnection
remarked to AF21 by the peering router of domain T, and domain T has with provider T is re-marked to AF21 by the peering router of domain
chosen to use MPLS Traffic Class value 2 for this aggregate. At the T, and domain T has chosen to use MPLS TC value 2 for this aggregate.
penultimate MPLS node, the top MPLS label is removed and exposes the At the penultimate MPLS node, the top MPLS label is removed and
IP header marked by the DSCP that has been set at the network exposes the IP header marked by the DSCP that has been set at the
ingress. The peering router connecting domain T with domain F network ingress. The peering router connecting domain T with domain
classifies the packet by its domain-T-internal DSCP AF21. As the F classifies the packet by its domain-T-internal DSCP AF21. As the
packet leaves domain T on the interface to domain F, this causes the packet leaves domain T on the interface to domain F, this causes the
packet's DSCP to be remarked to AF31. The peering router of domain F packet's DSCP to be re-marked to AF31. The peering router of domain
classifies the packet for domain-F-internal PHB AF11, as this is the F classifies the packet for domain-F-internal PHB AF11, as this is
PHB with properties matching Diffserv-Intercon's Assured Elastic the PHB with properties matching the Diffserv-Intercon Assured
Treatment Aggregate. Elastic Treatment Aggregate.
This example can be extended. The figure shows Provider-W using CS2 This example can be extended. The figure shows provider W using CS2
for traffic that corresponds to Diffserv-Intercon Assured Elastic for traffic that corresponds to Diffserv-Intercon Assured Elastic
Treatment Aggregate PHB AF31; that traffic is mapped to AF31 at the Treatment Aggregate PHB AF31; that traffic is mapped to AF31 at the
Diffserv-Intercon interconnection to Provider-T. In addition, Diffserv-Intercon interconnection to provider T. In addition,
suppose that Provider-O supports a PHB marked by AF22 and this PHB is suppose that provider O supports a PHB marked by AF22, and this PHB
supposed to obtain Diffserv transport within Provider-T domain. Then is supposed to obtain Diffserv transport within provider T's domain.
Provider-O will remark it with DSCP AF32 for interconnection to Then provider O will re-mark it with DSCP AF32 for interconnection to
Provider-T. provider T.
Finally suppose that Provider-W supports CS3 for internal use only. Finally, suppose that provider W supports CS3 for internal use only.
Then no Diffserv- Intercon DSCP mapping needs to be configured at the Then no Diffserv-Intercon DSCP mapping needs to be configured at the
peering router. Traffic, sent by Provider-W to Provider-T marked by peering router. Traffic, sent by provider W to provider T marked by
CS3 due to a misconfiguration may be remarked to CS0 by Provider-T. CS3 due to a misconfiguration may be re-marked to CS0 by provider T.
4.2. End-to-end PHB and DSCP Transparency 4.2. End-to-End PHB and DSCP Transparency
This section briefly discusses end-to-end Diffserv approaches related This section briefly discusses end-to-end Diffserv approaches related
to the Uniform, Pipe and Short Pipe tunnel models ([RFC2983], to the Uniform, Pipe, and Short Pipe Model tunnels [RFC2983]
[RFC3270]), when used edge-to-edge in a network. [RFC3270] when used edge-to-edge in a network.
o With the Uniform model, neither the DCSP nor the PHB change. This o With the Uniform Model, neither the DSCP nor the PHB change. This
implies that a network management packet received with a CS6 DSCP implies that a network management packet received with a CS6 DSCP
would be forwarded with an MPLS Traffic Class corresponding to would be forwarded with an MPLS TC corresponding to CS6. The
CS6. The uniform model is outside the scope of this document. Uniform Model is outside the scope of this document.
o With the Pipe model, the inner tunnel DCSP remains unchanged, but o With the Pipe Model, the inner tunnel DSCP remains unchanged, but
an outer tunnel DSCP and the PHB could changed. For example a an outer tunnel DSCP and the PHB could change. For example, a
packet received with a (network specific) CS1 DSCP would be packet received with a (network-specific) CS1 DSCP would be
transported by default PHB and if MPLS is applicable, forwarded transported by a Default PHB and, if MPLS is applicable, forwarded
with an MPLS Traffic Class corresponding to Default PHB. The CS1 with an MPLS TC corresponding to the Default PHB. The CS1 DSCP is
DSCP is not rewritten. Transport of a large variety (much greater not rewritten. Transport of a large variety (much greater than
than 4) DSCPs may be required across an interconnected network four) DSCPs may be required across an interconnected network
operating MPLS Short pipe transport for IP traffic. In that case, operating MPLS Short Pipe Model transport for IP traffic. In that
a tunnel based on the Pipe model is among the possible approaches. case, a tunnel based on the Pipe Model is among the possible
The Pipe model is outside the scope of this document. approaches. The Pipe Model is outside the scope of this document.
o With the Short Pipe model, the DCSP likely changes and the PHB o With the Short Pipe Model, the DSCP likely changes, and the PHB
might change. This document describes a method to simplify might change. This document describes a method to simplify
Diffserv network interconnection when a DSCP rewrite can't be Diffserv network interconnection when a DSCP rewrite can't be
avoided. avoided.
4.3. Treatment of Network Control traffic at carrier interconnection 4.3. Treatment of Network Control Traffic at Carrier Interconnection
interfaces Interfaces
As specified by RFC4594, section 3.2, Network Control (NC) traffic As specified in Section 3.2 of RFC 4594, NC traffic marked by CS6 is
marked by CS6 is expected at some interconnection interfaces. This expected at some interconnection interfaces. This document does not
document does not change RFC4594, but observes that network control change RFC 4594 but observes that network control traffic received at
traffic received at network ingress is generally different from a network ingress is generally different from network control traffic
network control traffic within a network that is the primary use of within a network that is the primary use of CS6 envisioned by RFC
CS6 envisioned by RFC4594. A specific example is that some CS6 4594. A specific example is that some CS6 traffic exchanged across
traffic exchanged across carrier interconnections is terminated at carrier interconnections is terminated at the network ingress node,
the network ingress node, e.g., when BGP is used between the two e.g., when BGP is used between the two routers on opposite ends of an
routers on opposite ends of an interconnection link; in this case the interconnection link; in this case, the operators would enter into a
operators would enter into a bilateral agreement to use CS6 for that bilateral agreement to use CS6 for that BGP traffic.
BGP traffic.
The end-to-end discussion in the previous section (4.2) is generally The end-to-end discussion in Section 4.2 is generally inapplicable to
inapplicable to network control traffic - network control traffic is network control traffic -- network control traffic is generally
generally intended to control a network, not be transported between intended to control a network, not be transported between networks.
networks. One exception is that network control traffic makes sense One exception is that network control traffic makes sense for a
for a purchased transit agreement, and preservation of the CS6 DSCP purchased transit agreement, and preservation of the CS6 DSCP marking
marking for network control traffic that is transited is reasonable for network control traffic that is transited is reasonable in some
in some cases, although it is generally inappropriate to use CS6 for cases, although it is generally inappropriate to use CS6 for
forwarding that traffic within the network that provides transit. forwarding that traffic within the network that provides transit.
Use of an IP tunnel is suggested in order to conceal the CS6 markings Use of an IP tunnel is suggested in order to conceal the CS6 markings
on transiting network control traffic from the network that provides on transiting network control traffic from the network that provides
the transit. In this case, Pipe model for Diffserv tunneling is the transit. In this case, the Pipe Model for Diffserv tunneling is
used. used.
If the MPLS Short Pipe model is deployed for unencapsulated IPv4 If the MPLS Short Pipe Model is deployed for unencapsulated IPv4
traffic, an IP network provider should limit access to the CS6 and traffic, an IP network provider should limit access to the CS6 and
CS7 DSCPs so that they are only used for network control traffic for CS7 DSCPs, so that they are only used for network control traffic for
the provider's own network. the provider's own network.
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 that is to be forwarded
forwarded beyond the ingress node. An SLA covering the following beyond the ingress node. An SLA covering the following cases is
cases is recommended when a provider wishes to send CS6 marked recommended when a provider wishes to send CS6-marked traffic across
traffic across an interconnection link and that traffic's destination an interconnection link and that traffic's destination is beyond the
is beyond the interconnected ingress node: interconnected ingress node:
o classification of traffic that is network control traffic for both o classification of traffic that is network control traffic for both
domains. This traffic should be classified and marked for the CS6 domains. This traffic should be classified and marked for the CS6
DSCP. DSCP.
o classification of traffic that is network control traffic for the o classification of traffic that is network control traffic for the
sending domain only. This traffic should be forwarded with a PHB sending domain only. This traffic should be forwarded with a PHB
that is appropriate for the NC service class [RFC4594], e.g., AF31 that is appropriate for transiting NC service class traffic
as specified by this document. As an example GSMA IR.34 [RFC4594] in the receiving domain, e.g., AF31 as specified by this
recommends an Interactive class / AF31 to carry SIP and DIAMETER document. As an example, GSMA IR.34 recommends an Interactive
traffic. While this is service control traffic of high importance class / AF31 to carry SIP and DIAMETER traffic. While this is
to interconnected Mobile Network Operators, it is certainly not service control traffic of high importance to interconnected
Network Control traffic for a fixed network providing transit Mobile Network Operators, it is certainly not network control
among such operators, and hence should not receive CS6 treatment traffic for a fixed network providing transit among such operators
in such a transit network. and hence should not receive CS6 treatment in such a transit
network.
o any other CS6 marked traffic should be remarked or dropped.
5. Acknowledgements
Bob Briscoe and Gorry Fairhurst reviewed the draft and provided rich o any other CS6-marked traffic should be re-marked or dropped.
feedback. Brian Carpenter, Fred Baker, Al Morton and Sebastien
Jobert discussed the draft and helped improving it. Mohamed
Boucadair and Thomas Knoll helped adding awareness of related work.
James Polk's discussion during IETF 89 helped to improve the text on
the relation of this draft to RFC4594 and RFC5127.
6. IANA Considerations 5. IANA Considerations
This memo includes no request to IANA. This document does not require any IANA actions.
7. Security Considerations 6. Security Considerations
The DSCP field in the IP header can expose additional traffic The DSCP field in the IP header can expose additional traffic
classification information at network interconnections by comparison classification information at network interconnections by comparison
to use of a zero DSCP for all interconnect traffic. If traffic to the use of a zero DSCP for all interconnect traffic. If traffic
classification info is sensitive, the DSCP field could be remarked to classification information is sensitive, the DSCP field could be
zero to hide the classification as a countermeasure, at the cost of re-marked to zero to hide the classification as a countermeasure, at
loss of Diffserv info and differentiated traffic handling on the the cost of loss of Diffserv information and differentiated traffic
interconnect and subsequent networks. When AF PHBs are used, any handling on the interconnect and subsequent networks. When AF PHBs
such remarking should respect AF PHB group boundaries as further are used, any such re-marking should respect AF PHB group boundaries
discussed at the end of Section 4. as further discussed at the end of Section 4.
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 Diffserv security considerations in [RFC2475] use existing ones. The Diffserv security considerations in [RFC2475]
and [RFC4594] apply. and [RFC4594] apply.
8. References 7. References
8.1. Normative References 7.1. Normative References
[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,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <http://www.rfc-editor.org/info/rfc2474>.
[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, "Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999, DOI 10.17487/RFC2597, June 1999,
skipping to change at page 16, line 45 skipping to change at page 16, line 41
[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, DOI 10.17487/RFC5129, January Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <http://www.rfc-editor.org/info/rfc5129>. 2008, <http://www.rfc-editor.org/info/rfc5129>.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic", Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, DOI 10.17487/RFC5865, May 2010, RFC 5865, DOI 10.17487/RFC5865, May 2010,
<http://www.rfc-editor.org/info/rfc5865>. <http://www.rfc-editor.org/info/rfc5865>.
8.2. Informative References 7.2. Informative References
[I-D.knoll-idr-cos-interconnect] [BGP-INTERCONNECTION]
Knoll, T., "BGP Class of Service Interconnection", draft- Knoll, T., "BGP Class of Service Interconnection", Work in
knoll-idr-cos-interconnect-17 (work in progress), November Progress, draft-knoll-idr-cos-interconnect-17, November
2016. 2016.
[ID.ietf-idr-sla] [IR.34] GSMA, "Guidelines for IPX Provider networks (Previously
IETF, "Inter-domain SLA Exchange", IETF, Inter-Service Provider IP Backbone Guidelines)", Official
http://datatracker.ietf.org/doc/ Document IR.34, Version 11.0, November 2014,
draft-ietf-idr-sla-exchange/, 2013. <http://www.gsma.com/newsroom/wp-content/uploads/
IR.34-v11.0.pdf>.
[IR.34] GSMA Association, "IR.34 Inter-Service Provider IP
Backbone Guidelines Version 7.0", GSMA, GSMA IR.34
http://www.gsma.com/newsroom/wp-content/uploads/2012/03/
ir.34.pdf, 2012.
[MEF23.1] MEF, "Implementation Agreement MEF 23.1 Carrier Ethernet [MEF23.1] MEF, "Implementation Agreement MEF 23.1: Carrier Ethernet
Class of Service Phase 2", MEF, MEF23.1 Class of Service - Phase 2", MEF 23.1, January 2012,
http://metroethernetforum.org/PDF_Documents/technical- <http://metroethernetforum.org/PDF_Documents/
specifications/MEF_23.1.pdf, 2012. technical-specifications/MEF_23.1.pdf>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>. <http://www.rfc-editor.org/info/rfc2475>.
[RFC2983] Black, D., "Differentiated Services and Tunnels", [RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000, RFC 2983, DOI 10.17487/RFC2983, October 2000,
<http://www.rfc-editor.org/info/rfc2983>. <http://www.rfc-editor.org/info/rfc2983>.
skipping to change at page 18, line 5 skipping to change at page 17, line 43
[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, DOI 10.17487/RFC5160, March Service (QoS)", RFC 5160, DOI 10.17487/RFC5160, March
2008, <http://www.rfc-editor.org/info/rfc5160>. 2008, <http://www.rfc-editor.org/info/rfc5160>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657, (Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015, DOI 10.17487/RFC7657, November 2015,
<http://www.rfc-editor.org/info/rfc7657>. <http://www.rfc-editor.org/info/rfc7657>.
[SLA-EXCHANGE]
Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M.
Boucadair, "Inter-domain SLA Exchange Attribute", Work in
Progress, draft-ietf-idr-sla-exchange-10, January 2017.
[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, Internet protocol and multiprotocol
networks", ITU, label switching networks", ITU-T Recommendation Y.1566,
http://www.itu.int/rec/T-REC-Y.1566-201207-I/en, 2012. July 2012,
<http://www.itu.int/rec/T-REC-Y.1566-201207-I/en>.
Appendix A. Appendix A The MPLS Short Pipe Model and IP traffic Appendix A. The MPLS Short Pipe Model and IP Traffic
The MPLS Short Pipe Model (or penultimate Hop Label Popping) is The MPLS Short Pipe Model (or penultimate hop label popping) is
widely deployed in carrier networks. If unencapsulated IP traffic is widely deployed in carrier networks. If unencapsulated IP traffic is
transported using MPLS Short Pipe, IP headers appear inside the last transported using MPLS Short Pipe, IP headers appear inside the last
section of the MPLS domain. This impacts the number of PHBs and section of the MPLS domain. This impacts the number of PHBs and
DSCPs that a network provider can reasonably support. See Figure 2 DSCPs that a network provider can reasonably support. See Figure 2
(below) for an example. for an example.
For encapsulated IP traffic, only the outer tunnel header is relevant For encapsulated IP traffic, only the outer tunnel header is relevant
for forwarding. If the tunnel does not terminate within the MPLS for forwarding. If the tunnel does not terminate within the MPLS
network section, only the outer tunnel DSCP is involved, as the inner network section, only the outer tunnel DSCP is involved, as the inner
DSCP does not affect forwarding behavior; in this case all DSCPs DSCP does not affect forwarding behavior; in this case, all DSCPs
could be used in the inner IP header without affecting network could be used in the inner IP header without affecting network
behavior based on the outer MPLS header. Here the Pipe model behavior based on the outer MPLS header. Here, the Pipe Model
applies. applies.
Layer 2 and Layer 3 VPN traffic all use an additional MPLS label; in Layer 2 and Layer 3 VPN traffic all use an additional MPLS label; in
this case, the MPLS tunnel follows the Pipe model. Classification this case, the MPLS tunnel follows the Pipe Model. Classification
and queuing within an MPLS network is always based on an MPLS label, and queuing within an MPLS network is always based on an MPLS label,
as opposed to the outer IP header. as opposed to the outer IP header.
Carriers often select PHBs and DSCP without regard to Carriers often select PHBs and DSCPs without regard to
interconnection. As a result PHBs and DSCPs typically differ between interconnection. As a result, PHBs and DSCPs typically differ
network carriers. With the exception of best effort traffic, a DSCP between network carriers. With the exception of best-effort traffic,
change should be expected at an interconnection at least for a DSCP change should be expected at an interconnection at least for
unencapsulated IP traffic, even if the PHB is suitably mapped by the unencapsulated IP traffic, even if the PHB is suitably mapped by the
carriers involved. carriers involved.
Although RFC3270 suggests that the Short Pipe Model is only Although RFC 3270 suggests that the Short Pipe Model is only
applicable to VPNs, current networks also use it to transport non- applicable to VPNs, current networks also use it to transport
tunneled IPv4 traffic. This is shown in figure 2 where Diffserv- non-tunneled IPv4 traffic. This is shown in Figure 2 where Diffserv-
Intercon is not used, resulting in exposure of the internal DSCPs of Intercon is not used, resulting in exposure of the internal DSCPs of
the upstream network to the downstream network across the the upstream network to the downstream network across the
interconnection. interconnection.
| |
\|/ IPv4, DSCP_send \|/ IPv4, DSCP_send
V V
| |
Peering Router Peering Router
| |
\|/ IPv4, DSCP_send \|/ IPv4, DSCP_send
V V
| |
MPLS Edge Router MPLS Edge Router
| Mark MPLS Label, TC_internal | Mark MPLS Label, TC_internal
\|/ Remark DSCP to \|/ Re-mark DSCP to
V (Inner: IPv4, DSCP_d) V (Inner: IPv4, DSCP_d)
| |
MPLS Core Router (penultimate hop label popping) MPLS Core Router (penultimate hop label popping)
| \ | \
| IPv4, DSCP_d | The DSCP needs to be in network- | IPv4, DSCP_d | The DSCP needs to be in network-
| ^^^^^^^^| internal Diffserv context. The Core | ^^^^^^^^| internal Diffserv context. The Core
\|/ > Router may require or enforce \|/ > Router may require or enforce
V | that. The Edge Router may wrongly V | that. The Edge Router may wrongly
| | classify, if the DSCP is not in | | classify, if the DSCP is not in
| / network-internal Diffserv context. | / network-internal Diffserv context.
MPLS Edge Router MPLS Edge Router
| \ Traffic leaves the network marked | \ Traffic leaves the network marked
\|/ IPv4, DSCP_d | with the network-internal \|/ IPv4, DSCP_d | with the network-internal
V > DSCP_d that must be dealt with V > DSCP_d that must be dealt with
| | by the next network (downstream). | | by the next network (downstream).
| / | /
Peer Router Peer Router
| Remark DSCP to | Re-mark DSCP to
\|/ IPv4, DSCP_send \|/ IPv4, DSCP_send
V V
| |
Short-Pipe / penultimate hop popping example
Figure 2 Figure 2: Short Pipe Model / Penultimate Hop Popping Example
The packets IP DSCP must be in a well understood Diffserv context for The packet's IP DSCP must be in a well-understood Diffserv context
schedulers and classifiers on the interfaces of the ultimate MPLS for schedulers and classifiers on the interfaces of the ultimate MPLS
link (last link traversed before leaving the network). The necessary link (last link traversed before leaving the network). The necessary
Diffserv context is network-internal and a network operating in this Diffserv context is network-internal, and a network operating in this
mode enforces DSCP usage in order to obtain robust differentiated mode enforces DSCP usage in order to obtain robust differentiated
forwarding behavior. forwarding behavior.
Without Diffserv-Intercon treatment, the traffic is likely to leave Without Diffserv-Intercon treatment, the traffic is likely to leave
each network marked with network-internal DSCP. DSCP_send in the each network marked with network-internal DSCP. DSCP_send in the
figure above has to be remarked into the first network's Diffserv figure above has to be re-marked into the first network's Diffserv
scheme at the ingress MPLS Edge Router, to DSCP_d in the example. scheme at the ingress MPLS Edge Router, to DSCP_d in the example.
For that reason, the traffic leaves this domain marked by the For that reason, the traffic leaves this domain marked by the
network-internal DSCP_d. This structure requires that every carrier network-internal DSCP_d. This structure requires that every carrier
deploys per-peer PHB and DSCP mapping schemes. deploys per-peer PHB and DSCP mapping schemes.
If Diffserv-Intercon is applied DSCPs for traffic transiting the If Diffserv-Intercon is applied, DSCPs for traffic transiting the
domain can be mapped from and remapped to an original DSCP. This is domain can be mapped from and remapped to an original DSCP. This is
shown in figure 3. Internal traffic may continue to use internal shown in Figure 3. Internal traffic may continue to use internal
DSCPs (e.g., DSCP_d) and they may also be used between a carrier and DSCPs (e.g., DSCP_d), and they may also be used between a carrier and
its direct customers. its direct customers.
Internal Router Internal Router
| |
| Outer Header | Outer Header
\|/ IPv4, DSCP_send \|/ IPv4, DSCP_send
V V
| |
Peering Router Peering Router
| Remark DSCP to | Re-mark DSCP to
\|/ IPv4, DSCP_ds-int Diffserv-Intercon DSCP and PHB \|/ IPv4, DSCP_ds-int Diffserv-Intercon DSCP and PHB
V V
| |
MPLS Edge Router MPLS Edge Router
| |
| Mark MPLS Label, TC_internal | Mark MPLS Label, TC_internal
\|/ Remark DSCP to \|/ Re-mark DSCP to
V (Inner: IPv4, DSCP_d) domain internal DSCP for V (Inner: IPv4, DSCP_d) Domain Internal DSCP for
| the PHB | the PHB
MPLS Core Router (penultimate hop label popping) MPLS Core Router (penultimate hop label popping)
| |
| IPv4, DSCP_d | IPv4, DSCP_d
| ^^^^^^ | ^^^^^^
\|/ \|/
V V
| |
| |
MPLS Edge Router--------------------+ MPLS Edge Router--------------------+
| | | |
\|/ Remark DSCP to \|/ IPv4, DSCP_d \|/ Re-mark DSCP to \|/ IPv4, DSCP_d
V IPv4, DSCP_ds-int V V IPv4, DSCP_ds-int V
| | | |
| | | |
Peer Router Domain internal Broadband Peer Router Domain Internal Broadband
| Access Router | Access Router
\|/ Remark DSCP to \|/ \|/ Re-mark DSCP to \|/
V IPv4, DSCP_send V IPv4, DSCP_d V IPv4, DSCP_send V IPv4, DSCP_d
| | | |
Short-Pipe example with Diffserv-Intercon Figure 3: Short Pipe Model Example with Diffserv-Intercon
Figure 3 Acknowledgements
Bob Briscoe and Gorry Fairhurst reviewed this specification and
provided rich feedback. Brian Carpenter, Fred Baker, Al Morton, and
Sebastien Jobert discussed the specification and helped improve it.
Mohamed Boucadair and Thomas Knoll helped by adding awareness of
related work. James Polk's discussion during IETF 89 helped to
improve the text on the relation of this specification to RFCs 4594
and 5127.
Authors' Addresses 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 David L. Black
skipping to change at page 22, line 17 skipping to change at page 21, line 30
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 David L. Black
Dell EMC Dell EMC
176 South Street 176 South Street
Hopkinton, MA Hopkinton, MA
USA United States of America
Phone: +1 (508) 293-7953 Phone: +1 (508) 293-7953
Email: david.black@dell.com Email: david.black@dell.com
 End of changes. 137 change blocks. 
506 lines changed or deleted 509 lines changed or added

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