Internet Engineering Task Force (IETF) R. Geib, Ed.
Request for Comments: 8100 Deutsche Telekom
Category: Informational D. Black
ISSN: 2070-1721 Dell EMC
March 2017
Internet Engineering Task Force (IETF) R. Geib, Ed.
Request for Comments: 8100 Deutsche Telekom
Category: Informational D. Black
ISSN: 2070-1721 Dell EMC
March 2017
Diffserv-Interconnection Classes and Practice
区分服务互连类与实践
Abstract
摘要
This document defines a limited common set of Diffserv Per-Hop Behaviors (PHBs) and Diffserv Codepoints (DSCPs) to be applied at (inter)connections of two separately administered and operated networks, and it explains how this approach can simplify network configuration and operation. Many network providers operate Multiprotocol Label Switching (MPLS) using Treatment Aggregates for traffic marked with different Diffserv Per-Hop Behaviors and use MPLS for interconnection with other networks. This document offers a simple interconnection approach that may simplify operation of Diffserv for network interconnection among providers that use MPLS and apply the Short Pipe Model. While motivated by the requirements of MPLS network operators that use Short Pipe Model tunnels, this document is applicable to other networks, both MPLS and non-MPLS.
本文档定义了一组有限的区分服务每跳行为（PHB）和区分服务代码点（DSCP），将应用于两个单独管理和操作的网络的（内部）连接，并解释了该方法如何简化网络配置和操作。许多网络提供商使用处理聚合来操作多协议标签交换（MPLS），处理标记为不同Diffserv每跳行为的流量，并使用MPLS与其他网络互连。本文档提供了一种简单的互连方法，可简化使用MPLS和应用短管模型的提供商之间网络互连的Diffserv操作。虽然本文件是基于使用短管模型隧道的MPLS网络运营商的要求，但也适用于其他网络，包括MPLS和非MPLS。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the 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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8100.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability Statement . . . . . . . . . . . . . . . . . 5
1.3. Document Organization . . . . . . . . . . . . . . . . . . 5
2. MPLS and Short Pipe Model Tunnels . . . . . . . . . . . . . . 6
3. Relationship to RFC 5127 . . . . . . . . . . . . . . . . . . 7
3.1. Background of RFC 5127 . . . . . . . . . . . . . . . . . 7
3.2. Differences from RFC 5127 . . . . . . . . . . . . . . . . 7
4. The Diffserv-Intercon Interconnection Classes . . . . . . . . 8
4.1. Diffserv-Intercon Example . . . . . . . . . . . . . . . . 11
4.2. End-to-End PHB and DSCP Transparency . . . . . . . . . . 13
4.3. Treatment of Network Control Traffic at Carrier
Interconnection Interfaces . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. The MPLS Short Pipe Model and IP Traffic . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability Statement . . . . . . . . . . . . . . . . . 5
1.3. Document Organization . . . . . . . . . . . . . . . . . . 5
2. MPLS and Short Pipe Model Tunnels . . . . . . . . . . . . . . 6
3. Relationship to RFC 5127 . . . . . . . . . . . . . . . . . . 7
3.1. Background of RFC 5127 . . . . . . . . . . . . . . . . . 7
3.2. Differences from RFC 5127 . . . . . . . . . . . . . . . . 7
4. The Diffserv-Intercon Interconnection Classes . . . . . . . . 8
4.1. Diffserv-Intercon Example . . . . . . . . . . . . . . . . 11
4.2. End-to-End PHB and DSCP Transparency . . . . . . . . . . 13
4.3. Treatment of Network Control Traffic at Carrier
Interconnection Interfaces . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. The MPLS Short Pipe Model and IP Traffic . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Diffserv has been deployed in many networks; it provides differentiated traffic forwarding based on the Diffserv Codepoint (DSCP) field, which is part of the IP header [RFC2474]. This document defines a set of common Diffserv classes (Per-Hop Behaviors (PHBs)) and codepoints for use at interconnection points to which and from which locally used classes and codepoints should be mapped.
Diffserv已经部署在许多网络中；它基于Diffserv Codepoint（DSCP）字段提供区分流量转发，该字段是IP报头[RFC2474]的一部分。本文档定义了一组通用的Diffserv类（每跳行为（PHB））和代码点，用于互连点，本地使用的类和代码点应映射到互连点和从互连点映射到互连点。
As described by Section 2.3.4.2 of [RFC2475], the re-marking of packets at domain boundaries is a Diffserv feature. If traffic marked with unknown or unexpected DSCPs is received, [RFC2474] recommends forwarding that traffic with default (best-effort) treatment without changing the DSCP markings to better support incremental Diffserv deployment in existing networks as well as with routers that do not support Diffserv or are not configured to support it. Many networks do not follow this recommendation and instead re-mark unknown or unexpected DSCPs to zero upon receipt for default (best-effort) forwarding in accordance with the guidance in [RFC2475] to ensure that appropriate DSCPs are used within a Diffserv domain. This document is based on the latter approach and defines additional DSCPs that are known and expected at network interconnection interfaces in order to reduce the amount of traffic whose DSCPs are re-marked to zero.
如[RFC2475]第2.3.4.2节所述，在域边界重新标记数据包是一种区分服务功能。如果接收到标记为未知或意外DSCP的流量，[RFC2474]建议在不更改DSCP标记的情况下使用默认（尽力）处理转发该流量，以便更好地支持现有网络以及不支持区分服务或未配置为支持它的路由器中的增量区分服务部署。许多网络不遵循此建议，而是根据[RFC2475]中的指南，在收到默认（尽力）转发时将未知或意外的DSCP重新标记为零，以确保在区分服务域中使用适当的DSCP。本文件基于后一种方法，并定义了网络互连接口处已知和预期的其他DSCP，以减少其DSCP重新标记为零的通信量。
This document is motivated by requirements for IP network interconnection with Diffserv support among providers that operate Multiprotocol Label Switching (MPLS) in their backbones, but it is also applicable to other technologies. The operational simplifications and methods in this document help align IP Diffserv functionality with MPLS limitations resulting from the widely deployed Short Pipe Model for MPLS tunnel operation [RFC3270]. Further, limiting Diffserv to a small number of Treatment Aggregates can enable network traffic to leave a network with the DSCP value with which it was received, even if a different DSCP is used within the network, thus providing an opportunity to extend consistent Diffserv treatment across network boundaries.
本文件的动机是要求在主干网中运行多协议标签交换（MPLS）的提供商之间进行IP网络互连，并提供Diffserv支持，但也适用于其他技术。本文档中的操作简化和方法有助于将IP区分服务功能与广泛部署的MPLS隧道操作短管模型[RFC3270]产生的MPLS限制相一致。此外，将Diffserv限制为少量的处理聚合可以使网络流量以接收到它的DSCP值离开网络，即使在网络内使用不同的DSCP，从而提供跨网络边界扩展一致的Diffserv处理的机会。
In isolation, use of a defined set of interconnection PHBs and DSCPs may appear to be additional effort for a network operator. The primary offsetting benefit is that mapping from or to the interconnection PHBs and DSCPs is specified once for all of the interconnections to other networks that can use this approach. Absent this approach, the PHBs and DSCPs have to be negotiated and configured independently for each network interconnection, which has poor administrative and operational scaling properties. Further,
单独而言，对网络运营商而言，使用一组定义的互连PHB和DSCP似乎是额外的工作。主要的抵消好处是，对于可以使用此方法的其他网络的所有互连，一次指定从互连PHB和DSCP到互连PHB和DSCP的映射。如果没有这种方法，PHB和DSCP必须为每个网络互连进行单独协商和配置，这具有较差的管理和操作扩展特性。进一步的
consistent end-to-end Diffserv treatment is more likely to result when an interconnection codepoint scheme is used because traffic is re-marked to the same DSCPs at all network interconnections.
当使用互连码点方案时，更可能产生一致的端到端区分服务处理，因为在所有网络互连中，流量都被重新标记到相同的DSCP。
The interconnection approach described in this document (referred to as "Diffserv-Intercon") uses a set of PHBs (mapped to four corresponding MPLS Treatment Aggregates) along with a set of interconnection DSCPs allowing straightforward rewriting to domain-internal DSCPs and defined DSCP markings for traffic forwarded to interconnected domains. The solution described here can be used in other contexts benefiting from a defined Diffserv interconnection interface.
本文件中描述的互连方法（称为“Diffserv Intercon”）使用一组PHB（映射到四个相应的MPLS处理聚合）以及一组互连DSCP，允许直接重写到域内部DSCP，并为转发到互连域的流量定义DSCP标记。这里描述的解决方案可用于受益于定义的Diffserv互连接口的其他环境中。
The basic idea is that traffic sent with a Diffserv-Intercon PHB and DSCP is restored to that PHB and DSCP at each network interconnection, even though a different PHB and DSCP may be used within each network involved. The key requirement is that the network ingress interconnect DSCP be restored at the network egress, and a key observation is that this is only feasible in general for a small number of DSCPs. Traffic sent with other DSCPs can be re-marked to an interconnect DSCP or dealt with via an additional agreement(s) among the operators of the interconnected networks; use of the MPLS Short Pipe Model favors re-marking unexpected DSCPs to zero in the absence of an additional agreement(s), as explained further in this document.
基本思想是，通过Diffserv Intercon PHB和DSCP发送的流量在每个网络互连时恢复到该PHB和DSCP，即使在每个涉及的网络中可能使用不同的PHB和DSCP。关键要求是在网络出口处恢复网络入口互连DSCP，关键观察结果是，这通常仅适用于少量DSCP。与其他DSCP一起发送的流量可重新标记为互连DSCP，或通过互连网络运营商之间的附加协议进行处理；使用MPLS短管模型有利于在没有额外协议的情况下将意外DSCP重新标记为零，如本文档中进一步解释的。
In addition to the common interconnecting PHBs and DSCPs, interconnecting operators need to further agree on the tunneling technology used for interconnection (e.g., MPLS, if used) and control or mitigate the impacts of tunneling on reliability and MTU.
除了常见的互连PHB和DSCP外，互连运营商还需要进一步商定用于互连的隧道技术（如使用MPLS），并控制或减轻隧道对可靠性和MTU的影响。
In addition to the activities that triggered this work, there are additional RFCs and Internet-Drafts that may benefit from an interconnection PHB and DSCP scheme. [RFC5160] suggests Meta-QoS-Classes to help enable deployment of standardized end-to-end QoS classes. The Diffserv-Intercon class and codepoint scheme is intended to complement that work (e.g., by enabling a defined set of interconnection DSCPs and PHBs).
除了触发这项工作的活动外，还有其他RFC和互联网草案可能受益于互连PHB和DSCP方案。[RFC5160]建议使用元QoS类来帮助部署标准化的端到端QoS类。Diffserv Intercon类和代码点方案旨在补充这项工作（例如，通过启用一组定义的互连DSCP和PHB）。
Border Gateway Protocol (BGP) support for signaling Class of Service at interconnection interfaces [BGP-INTERCONNECTION] [SLA-EXCHANGE] is complementary to Diffserv-Intercon. These two BGP documents focus on exchanging Service Level Agreement (SLA) and traffic conditioning parameters and assume that common PHBs identified by the signaled DSCPs have been established (e.g., via use of the Diffserv-Intercon DSCPs) prior to BGP signaling of PHB id codes.
边界网关协议（BGP）支持互连接口处的信令服务等级[BGP-interconnection][SLA-EXCHANGE]是对Diffserv Intercon的补充。这两份BGP文件侧重于交换服务水平协议（SLA）和流量调节参数，并假设在BGP发送PHB id码之前，已建立由发信号的DSCP识别的公共PHB（例如，通过使用Diffserv Intercon DSCP）。
This document is applicable to the use of Differentiated Services for interconnection traffic between networks and is particularly suited to interconnection of MPLS-based networks that use MPLS Short Pipe Model tunnels. This document is also applicable to other network technologies, but it is not intended for use within an individual network, where the approach specified in [RFC5127] is among the possible alternatives; see Section 3 for further discussion.
本文件适用于网络间互连流量的区分服务的使用，特别适用于使用MPLS短管模型隧道的基于MPLS的网络的互连。本文件也适用于其他网络技术，但不适用于单个网络，其中[RFC5127]中规定的方法是可能的替代方法之一；进一步讨论见第3节。
The Diffserv-Intercon approach described in this document simplifies IP-based interconnection to domains operating the MPLS Short Pipe Model for IP traffic, both terminating within the domain and transiting onward to another domain. Transiting traffic is received and sent with the same PHB and DSCP. Terminating traffic maintains the PHB with which it was received; however, the DSCP may change.
本文档中描述的Diffserv Intercon方法简化了与使用MPLS短管模型进行IP通信的域之间基于IP的互连，这些域在域内终止，并向前过渡到另一个域。使用相同的PHB和DSCP接收和发送传输流量。终止通信维护接收到它的PHB；但是，DSCP可能会发生变化。
Diffserv-Intercon is also applicable to Pipe Model tunneling [RFC2983] [RFC3270], but it is not applicable to Uniform Model tunneling [RFC2983] [RFC3270].
Diffserv Intercon也适用于管道模型隧道[RFC2983][RFC3270]，但不适用于统一模型隧道[RFC2983][RFC3270]。
The Diffserv-Intercon approach defines a set of four PHBs for support at interconnections (or network boundaries in general). Corresponding DSCPs for use at an interconnection interface are also defined. Diffserv-Intercon allows for a simple mapping of PHBs and DSCPs to MPLS Treatment Aggregates. It is extensible by IETF standardization, and this allows additional PHBs and DSCPs to be specified for the Diffserv-Intercon scheme. Coding space for private interconnection agreements or provider internal services is available, as only a single digit number of standard DSCPs are applied by the Diffserv-Intercon approach.
Diffserv Intercon方法定义了一组四个PHB，用于支持互连（或一般的网络边界）。还定义了用于互连接口的相应DSCP。Diffserv Intercon允许将PHB和DSCP简单映射到MPLS处理聚合。它可以通过IETF标准化进行扩展，这允许为Diffserv Intercon方案指定额外的PHB和DSCP。专用互连协议或提供商内部服务的编码空间可用，因为Diffserv Intercon方法只应用了一位数的标准DSCP。
This document is organized as follows: Section 2 reviews the MPLS Short Pipe Model for Diffserv Tunnels [RFC3270], because effective support for that model is a crucial goal of Diffserv-Intercon. Section 3 provides background on the approach described in RFC 5127 to Traffic Class (TC) aggregation within a Diffserv network domain and contrasts it with the Diffserv-Intercon approach. Section 4 introduces Diffserv-Intercon Treatment Aggregates, along with the PHBs and DSCPs that they use, and explains how other PHBs (and associated DSCPs) may be mapped to these Treatment Aggregates. Section 4 also discusses treatment of IP traffic, MPLS VPN Diffserv considerations, and the handling of high-priority network management traffic. Appendix A describes how the MPLS Short Pipe Model (Penultimate Hop Popping (PHP)) impacts DSCP marking for IP interconnections.
本文档组织如下：第2节回顾了区分服务隧道的MPLS短管模型[RFC3270]，因为有效支持该模型是区分服务Intercon的一个关键目标。第3节提供了RFC 5127中描述的在Diffserv网络域内进行流量类（TC）聚合的方法的背景，并将其与Diffserv Intercon方法进行了对比。第4节介绍了Diffserv Intercon处理聚合以及它们使用的PHB和DSCP，并解释了其他PHB（和相关DSCP）如何映射到这些处理聚合。第4节还讨论了IP流量的处理、MPLS VPN区分服务注意事项以及高优先级网络管理流量的处理。附录A描述了MPLS短管模型（倒数第二跳弹出（PHP））如何影响IP互连的DSCP标记。
This section provides a summary of the implications of MPLS Short Pipe Model tunnels and, in particular, their use of PHP (see RFC 3270) on the Diffserv tunnel framework described in RFC 2983. The Pipe and Uniform Models for Differentiated Services and Tunnels are defined in [RFC2983]. RFC 3270 adds the Short Pipe Model to reflect the impact of MPLS PHP, primarily for MPLS-based IP tunnels and VPNs. The Short Pipe Model and PHP have subsequently become popular with network providers that operate MPLS networks and are now widely used to transport unencapsulated IP traffic. This has important implications for Diffserv functionality in MPLS networks.
本节概述了MPLS短管模型隧道的含义，特别是它们在RFC 2983中描述的Diffserv隧道框架上使用PHP（参见RFC 3270）。[RFC2983]中定义了区分服务和隧道的管道和统一模型。RFC 3270添加了短管模型以反映MPLS PHP的影响，主要用于基于MPLS的IP隧道和VPN。短管模型和PHP随后在运行MPLS网络的网络提供商中流行起来，现在被广泛用于传输未封装的IP流量。这对MPLS网络中的区分服务功能具有重要意义。
Per RFC 2474, the recommendation to forward traffic with unrecognized DSCPs with default (best-effort) service without rewriting the DSCP has not been widely deployed in 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, and a common practice is to re-mark to CS0 any traffic received with unrecognized or unsupported DSCPs at network edges.
根据RFC 2474，使用默认（尽力）服务转发具有未识别DSCP的流量而不重写DSCP的建议在实践中并未得到广泛部署。当数据包上标记的DSCP与网络节点应用的转发处理（PHB）之间存在1-1匹配时，网络操作和管理得到简化。完成此操作后，CS0（全零DSCP）是用于尽力而为流量默认转发的唯一DSCP，通常的做法是将在网络边缘使用未识别或不支持的DSCP接收的任何流量重新标记为CS0。
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. If the MPLS label with the provider's TC field is present at all hops within the provider network, this approach would allow an unrecognized DSCP to be carried edge-to-edge over an MPLS network, because the effective DSCP used by the provider's MPLS network would be encoded in the MPLS label TC field (and also carried edge-to-edge). Unfortunately, this is only true for Pipe Model tunnels.
在这方面，MPLS网络更微妙，因为可以在MPLS TC字段中编码提供商的DSCP，并允许其与MPLS封装的IP分组中由DSCP指示的PHB不同。如果在提供商网络内的所有跃点上都存在带有提供商TC字段的MPLS标签，则此方法将允许通过MPLS网络边对边传送未识别的DSCP，因为提供商的MPLS网络使用的有效DSCP将在MPLS标签TC字段中编码（并且也是边对边传送）。不幸的是，这仅适用于管道模型隧道。
Short Pipe Model tunnels and PHP behave differently because PHP removes and discards the MPLS provider label carrying the provider's TC field before the traffic exits the provider's network. That discard occurs one hop upstream of the MPLS tunnel endpoint (which is usually at the network edge), resulting in no provider TC information being available at the tunnel egress. To ensure consistent handling of traffic at the tunnel egress, the DSCP field in the MPLS-encapsulated IP header has to contain a DSCP that is valid for the provider's network, so that the IP header cannot be used to carry a different DSCP edge-to-edge. See Appendix A for a more detailed discussion.
短管模型隧道和PHP的行为不同，因为PHP在流量退出提供商的网络之前删除并丢弃携带提供商TC字段的MPLS提供商标签。该丢弃发生在MPLS隧道端点（通常在网络边缘）上游一跳，导致在隧道出口处没有可用的提供商TC信息。为确保隧道出口处的流量处理一致，MPLS封装IP报头中的DSCP字段必须包含对提供商网络有效的DSCP，以便IP报头不能用于承载不同的DSCP边到边。有关更详细的讨论，请参见附录A。
This document draws heavily upon the approach to aggregation of Diffserv TCs for use within a network as described in RFC 5127, but there are important differences caused by characteristics of network interconnects that differ from links within a network.
本文件大量采用RFC 5127中所述的聚合网络内使用的Diffserv TC的方法，但由于网络互连的特性不同于网络内的链路，因此存在重大差异。
Many providers operate MPLS-based backbones that employ backbone traffic engineering to ensure that if a major link, switch, or router fails, the result will be a routed network that continues to function. Based on that foundation, [RFC5127] introduced the concept of Diffserv Treatment Aggregates, which enable traffic marked with multiple DSCPs to be forwarded in a single MPLS TC based on robust provider backbone traffic engineering. This enables differentiated forwarding behaviors within a domain in a fashion that does not consume a large number of MPLS TCs.
许多提供商运营基于MPLS的主干网，这些主干网采用主干网流量工程，以确保如果主链路、交换机或路由器出现故障，其结果将是路由网络继续运行。基于此基础，[RCF5127]引入了DiffServ处理聚集的概念，它使得基于多个DSCPS的业务能够基于鲁棒的提供商骨干业务工程在单个MPLS TC中转发。这以不消耗大量MPLS TC的方式实现域内的差异化转发行为。
RFC 5127 provides an example aggregation of Diffserv service classes into four Treatment Aggregates. A small number of aggregates are used because:
RFC 5127提供了将Diffserv服务类聚合为四个处理聚合的示例。使用少量骨料是因为：
o The available coding space for carrying TC information (e.g., Diffserv PHB) in MPLS (and Ethernet) is only 3 bits in size and is intended for more than just Diffserv purposes (see, e.g., [RFC5129]).
o 用于在MPLS（和以太网）中承载TC信息（例如，区分服务PHB）的可用编码空间的大小仅为3位，并且不仅仅用于区分服务目的（参见，例如，[RFC5129]）。
o The common interconnection DSCPs ought not to use all 8 possible values. This leaves space for future standards, private bilateral agreements, and local use PHBs and DSCPs.
o 通用互连DSCP不应使用所有8个可能值。这为未来的标准、私人双边协议和本地使用PHB和DSCP留下了空间。
o Migrations from one DSCP scheme to a different one is another possible application of otherwise unused DSCPs.
o 从一个DSCP方案迁移到另一个方案是未使用的DSCP的另一种可能应用。
Like RFC 5127, this document also uses four Treatment Aggregates, but it differs from RFC 5127 in some important ways:
与RFC 5127一样，本文件也使用了四种处理骨料，但在一些重要方面与RFC 5127不同：
o It follows RFC 2475 in allowing the DSCPs used within a network to differ from those used to exchange traffic with other networks (at network edges), but it provides support to restore ingress DSCP values if one of the recommended interconnect DSCPs in this document is used. This results in DSCP re-marking at both network ingress and network egress, and this document assumes that such re-marking at network edges is possible for all interface types.
o 它遵循RFC 2475，允许网络中使用的DSCP不同于用于与其他网络（在网络边缘）交换流量的DSCP，但如果使用本文档中推荐的互连DSCP之一，它提供了恢复入口DSCP值的支持。这将导致在网络入口和网络出口处进行DSCP重新标记，本文件假设所有接口类型均可在网络边缘进行此类重新标记。
o Diffserv-Intercon suggests limiting the number of interconnection PHBs per Treatment Aggregate to the minimum required. As further discussed below, the number of PHBs per Treatment Aggregate is no more than two. When two PHBs are specified for a Diffserv-Intercon Treatment Aggregate, the expectation is that the provider network supports DSCPs for both PHBs but uses a single MPLS TC for the Treatment Aggregate that contains the two PHBs.
o Diffserv Intercon建议将每个处理集总的互连PHB数量限制在所需的最低限度。如下文所述，每个处理骨料的PHB数量不超过两个。当为Diffserv Intercon治疗聚合指定两个PHB时，期望提供商网络支持两个PHB的DSCP，但对包含两个PHB的治疗聚合使用单个MPLS TC。
o Diffserv-Intercon suggests mapping other PHBs and DSCPs into the interconnection Treatment Aggregates as further discussed below.
o Diffserv Intercon建议将其他PHB和DSCP映射到互连处理聚合中，如下所述。
o Diffserv-Intercon treats network control (NC) traffic as a special case. Within a provider's network, the CS6 DSCP is used for local network control traffic (routing protocols and Operations, Administration, and Maintenance (OAM) traffic that is essential to network operation administration, control, and management) that may be destined for any node within the network. In contrast, network control traffic exchanged between networks (e.g., BGP) usually terminates at or close to a network edge and is not forwarded through the network because it is not part of internal routing or OAM for the receiving network. In addition, such traffic is unlikely to be covered by standard interconnection agreements; rather, it is more likely to be specifically configured (e.g., most networks impose restrictions on use of BGP with other networks for obvious reasons). See Section 4.2 for further discussion.
o Diffserv Intercon将网络控制（NC）流量视为特例。在提供商的网络中，CS6 DSCP用于本地网络控制流量（路由协议和操作、管理和维护（OAM）流量，这对于网络操作管理、控制和管理至关重要），这些流量可能以网络中的任何节点为目的地。相反，网络（例如，BGP）之间交换的网络控制流量通常终止于或接近网络边缘，并且不通过网络转发，因为它不是接收网络的内部路由或OAM的一部分。此外，标准互连协议不太可能涵盖此类流量；相反，它更可能是专门配置的（例如，由于明显的原因，大多数网络对BGP与其他网络的使用施加限制）。进一步讨论见第4.2节。
o Because RFC 5127 used a Treatment Aggregate for network control traffic, Diffserv-Intercon can instead define a fourth Treatment Aggregate for use at network interconnections instead of the Network Control Treatment Aggregate in RFC 5127. Network control traffic may still be exchanged across network interconnections as further discussed in Section 4.2. Diffserv-Intercon uses this fourth Treatment Aggregate for Voice over IP (VoIP) traffic, where network-provided service differentiation is crucial, as even minor glitches are immediately apparent to the humans involved in the conversation.
o 由于RFC 5127对网络控制流量使用了处理聚合，因此Diffserv Intercon可以定义第四个处理聚合，用于网络互连，而不是RFC 5127中的网络控制处理聚合。如第4.2节所述，网络控制流量仍可通过网络互连进行交换。Diffserv Intercon将这第四种处理聚合用于IP语音（VoIP）流量，其中网络提供的服务差异化至关重要，因为即使是微小的故障也会立即对参与对话的人员显现出来。
At an interconnection, the networks involved need to agree on the PHBs used for interconnection and the specific DSCP for each PHB. This document defines a set of four interconnection Treatment Aggregates with well-defined DSCPs to be aggregated by them. A sending party re-marks DSCPs from internal usage to the interconnection codepoints. The receiving party re-marks DSCPs to their internal usage. The interconnect SLA defines the set of DSCPs and PHBs supported across the two interconnected domains and the
在互连时，所涉及的网络需要就用于互连的PHB和每个PHB的特定DSCP达成一致。本文件定义了一组由四个互连处理聚合组成的集合，其中定义明确的DSCP将由它们聚合。发送方将DSCP从内部使用重新标记到互连代码点。接收方将DSCP重新标记为其内部用途。互连SLA定义了跨两个互连域和
treatment of PHBs and DSCPs that are not recognized by the receiving domain.
处理接收域无法识别的PHB和DSCP。
Similar approaches that use a small number of Treatment Aggregates (including recognition of the importance of VoIP traffic) have been taken in related standards and recommendations from outside the IETF, e.g., Y.1566 [Y.1566], Global System for Mobile Communications Association (GSMA) IR.34 [IR.34], and MEF23.1 [MEF23.1].
IETF之外的相关标准和建议中采用了类似的方法，使用了少量处理聚合（包括对VoIP流量重要性的认识），例如Y.1566[Y.1566]、全球移动通信系统协会（GSMA）IR.34[IR.34]和MEF23.1[MEF23.1]。
The list of the four Diffserv-Intercon Treatment Aggregates follows, highlighting differences from RFC 5127 and suggesting mappings for all RFC 4594 TCs to Diffserv-Intercon Treatment Aggregates:
四个Diffserv Intercon治疗集总列表如下，突出显示了与RFC 5127的差异，并建议将所有RFC 4594 TC映射到Diffserv Intercon治疗集总：
Telephony Service Treatment Aggregate: PHB Expedited Forwarding (EF), DSCP 101 110 and PHB VOICE-ADMIT, DSCP 101 100 (see [RFC3246], [RFC4594], and [RFC5865]). This Treatment Aggregate corresponds to the Real-Time Treatment Aggregate definition regarding the queuing (both delay and jitter should be minimized) per RFC 5127, but this aggregate is restricted to transport Telephony service class traffic in the sense of [RFC4594].
电话服务处理聚合：PHB快速转发（EF）、DSCP 101 110和PHB语音接收、DSCP 101 100（参见[RFC3246]、[RFC4594]和[RFC5865]）。根据RFC 5127，该处理聚合对应于关于排队（延迟和抖动应最小化）的实时处理聚合定义，但该聚合仅限于[RFC4594]意义上的传输电话服务类流量。
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 intended to provide Diffserv-Intercon network interconnection of a subset of the Real-Time Treatment Aggregate defined in RFC 5127, specifically the portions that consume significant bandwidth. This traffic is expected to consist of the following classes defined in RFC 4594: Broadcast Video, Real-Time Interactive, and Multimedia Conferencing. This Treatment Aggregate should be configured with a rate-based queue (consistent with the recommendation 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 is a need for three-color marked Multimedia Conferencing traffic.
批量实时处理骨料：该处理骨料设计用于运输PHB AF41、DSCP 100 010（其他AF4 PHB组PHB和DSCP可用于该处理骨料携带的DSCP集的未来扩展）。该处理聚合旨在提供RFC 5127中定义的实时处理聚合的子集的Diffserv Intercon网络互连，特别是消耗大量带宽的部分。该流量预计由RFC 4594中定义的以下类别组成：广播视频、实时交互和多媒体会议。应使用基于速率的队列配置此处理聚合（与RFC 4594中传输的TC的建议一致）。与RFC 5127相比，DSCP的数量已减少到一个（最初）。如果需要三种颜色标记的多媒体会议流量，可以添加AF42和AF43 PHB。
Assured Elastic Treatment Aggregate: This Treatment Aggregate consists of PHBs AF31 and AF32 (i.e., DSCPs 011 010 and 011 100). By comparison to RFC 5127, the number of DSCPs has been reduced to two. This document suggests to transport signaling marked by AF31 (e.g., as recommended by GSMA IR.34 [IR.34]). AF33 is reserved for the extension of PHBs to be aggregated by this Treatment Aggregate. For Diffserv-Intercon network interconnection, the following service
保证弹性处理骨料：该处理骨料由PHBs AF31和AF32组成（即DSCPs 011 010和011 100）。与RFC 5127相比，DSCP的数量已减少到两个。本文件建议传输标有AF31的信号（例如，按照GSMA IR.34[IR.34]的建议）。AF33保留用于通过该处理骨料聚合的PHB扩展。对于Diffserv Intercon网络互连，以下服务
classes (per RFC 4594) should be mapped to the Assured Elastic Treatment Aggregate: the Signaling service class (being marked for lowest loss probability), the Multimedia Streaming service class, the Low-Latency Data service class, and the High-Throughput Data service class.
类别（根据RFC 4594）应映射到保证的弹性处理聚合：信令服务类别（标记为最低丢失概率）、多媒体流服务类别、低延迟数据服务类别和高吞吐量数据服务类别。
Default / Elastic Treatment Aggregate: Transports the Default PHB, CS0 with DSCP 000 000. An example in RFC 5127 refers to this Treatment Aggregate as "Elastic Treatment Aggregate". An important difference from RFC 5127 is that any traffic with unrecognized or unsupported DSCPs may be re-marked to this DSCP. For Diffserv-Intercon network interconnection, the Standard service class and Low-Priority Data service class defined in RFC 4594 should be mapped to this Treatment Aggregate. This document does not specify an interconnection class for Low-Priority Data (also defined RFC 4594). This traffic may be forwarded with a Lower Effort PHB in one domain (e.g., the PHB proposed by Informational [RFC3662]), but the methods specified in this document re-mark this traffic with DSCP CS0 at a Diffserv-Intercon network interconnection. This has the effect that Low-Priority Data is treated the same as data sent using the Standard service class. (Note: In a network that implements RFC 2474, Low-Priority traffic marked as CS1 would otherwise receive better treatment than Standard traffic using the default PHB.)
默认/弹性处理聚合：使用DSCP 000传输默认PHB、CS0。RFC 5127中的示例将该处理骨料称为“弹性处理骨料”。与RFC 5127的一个重要区别是，任何具有无法识别或不支持的DSCP的流量都可能被重新标记到此DSCP。对于Diffserv Intercon网络互连，RFC 4594中定义的标准服务类和低优先级数据服务类应映射到此处理聚合。本文件未规定低优先级数据（也定义为RFC 4594）的互连类别。该流量可在一个域中以较低的努力PHB转发（例如，信息[RFC3662]提出的PHB），但本文件中规定的方法在Diffserv Intercon网络互连处使用DSCP CS0重新标记该流量。这会使低优先级数据与使用标准服务类发送的数据一样被处理。（注意：在实现RFC 2474的网络中，标记为CS1的低优先级流量将得到比使用默认PHB的标准流量更好的处理。）
RFC 2475 states that ingress nodes must condition all inbound traffic to ensure that the DS codepoints are acceptable; packets found to have unacceptable codepoints must either be discarded or 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 CS0. 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; re-marking to CS0 is a widely deployed behavior.
RFC 2475规定，入口节点必须调节所有入站流量，以确保DS码点是可接受的；被发现具有不可接受的代码点的数据包必须被丢弃，或者在转发之前将其DS代码点修改为可接受的值。例如，从不存在增强服务协议的域接收流量的入口节点可以将DS码点重置为CS0。因此，互连SLA不仅需要指定对使用受支持的互连DSCP到达的流量的处理，还需要指定对使用不受支持的或意外的DSCP到达的流量的处理；重新标记为CS0是一种广泛部署的行为。
During the process of setting up a Diffserv interconnection, both networks should define the set of acceptable and unacceptable DSCPs and specify the treatment of traffic marked with each DSCP.
在建立Diffserv互连的过程中，两个网络都应定义可接受和不可接受的DSCP集，并指定用每个DSCP标记的流量的处理。
While Diffserv-Intercon allows modification of unacceptable DSCPs, if 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 Diffserv-Intercon Treatment Aggregate, then traffic using other PHBs from the same PHB group should not be modified to use PHBs outside of that PHB group and, in particular, should not be re-marked
虽然Diffserv Intercon允许修改不可接受的DSCP，但如果使用PHB组中的一个或多个PHB（例如，AF3x，由AF31、AF32和AF33组成）的流量被接受为受支持的Diffserv Intercon处理集合的一部分，然后，使用来自同一PHB组的其他PHB的流量不应修改为使用该PHB组之外的PHB，尤其不应重新标记
to CS0 unless the entire PHB group is re-marked to CS0. This avoids unexpected forwarding behavior (and potential reordering; see also [RFC7657]) when using Assured Forwarding (AF) PHBs [RFC2597].
至CS0，除非整个PHB组重新标记为CS0。这避免了在使用保证转发（AF）PHB[RFC2597]时出现意外的转发行为（以及潜在的重新排序；另请参见[RFC7657]）。
The overall approach to DSCP marking at network interconnections is illustrated by the following example. Provider O, provider W, and provider F are peered with provider T. They have agreed upon a Diffserv interconnection SLA.
以下示例说明了在网络互连处进行DSCP标记的总体方法。提供商O、提供商W和提供商F与提供商T进行对等。他们已就区分服务互连SLA达成一致。
Traffic of provider O terminates within provider T's network, while provider W's traffic transits through the network of provider T to provider F. This example assumes that all providers use their own internal PHB and codepoint (DSCP) that correspond to the AF31 PHB in the Diffserv-Intercon Assured Elastic Treatment Aggregate (AF21, CS2, and AF11 are used in the example).
提供商O的通信量在提供商T的网络内终止，而提供商W的通信量通过提供商T的网络传输到提供商F。该示例假设所有提供商都使用自己的内部PHB和代码点（DSCP），它们对应于Diffserv Intercon保证弹性处理聚合中的AF31 PHB（示例中使用了AF21、CS2和AF11）。
Provider O Provider W
| |
+----------+ +----------+
| AF21 | | CS2 |
+----------+ +----------+
V V
+~~~~~~~+ +~~~~~~~+
|Rtr PrO| |Rtr PrW| Rtr: Router
+~~~~~~~+ +~~~~~~~+ Pr[L]: Provider[L]
| Diffserv |
+----------+ +----------+
| AF31 | | AF31 |
+----------+ +----------+
V Intercon V
+~~~~~~~+ |
|RtrPrTI|------------------+ Router Provider T Ingress
+~~~~~~~+
| Provider T Domain
+------------------+
| MPLS TC 2, AF21 |
+------------------+
| | +----------+ +~~~~~~~+
V `--->| AF21 |->-|RtrDstH| Router Destination Host
+----------+ +----------+ +~~~~~~~+
| AF21 | Local DSCPs Provider T
+----------+
|
+~~~~~~~+
|RtrPrTE| Router Provider T Egress
+~~~~~~~+
| Diffserv
+----------+
| AF31 |
+----------+
| Intercon
+~~~~~~~+
|RtrPrF | Router Provider F
+~~~~~~~+
|
+----------+
| AF11 | Provider F
+----------+
Provider O Provider W
| |
+----------+ +----------+
| AF21 | | CS2 |
+----------+ +----------+
V V
+~~~~~~~+ +~~~~~~~+
|Rtr PrO| |Rtr PrW| Rtr: Router
+~~~~~~~+ +~~~~~~~+ Pr[L]: Provider[L]
| Diffserv |
+----------+ +----------+
| AF31 | | AF31 |
+----------+ +----------+
V Intercon V
+~~~~~~~+ |
|RtrPrTI|------------------+ Router Provider T Ingress
+~~~~~~~+
| Provider T Domain
+------------------+
| MPLS TC 2, AF21 |
+------------------+
| | +----------+ +~~~~~~~+
V `--->| AF21 |->-|RtrDstH| Router Destination Host
+----------+ +----------+ +~~~~~~~+
| AF21 | Local DSCPs Provider T
+----------+
|
+~~~~~~~+
|RtrPrTE| Router Provider T Egress
+~~~~~~~+
| Diffserv
+----------+
| AF31 |
+----------+
| Intercon
+~~~~~~~+
|RtrPrF | Router Provider F
+~~~~~~~+
|
+----------+
| AF11 | Provider F
+----------+
Figure 1: Diffserv-Intercon Example
图1：Diffserv Intercon示例
Providers only need to deploy mappings of internal DSCPs to/from Diffserv-Intercon DSCPs, so that they can exchange traffic using the desired PHBs. In the example, provider O has decided that the properties of his internal class AF21 are best met by the Diffserv-Intercon Assured Elastic Treatment Aggregate, PHB AF31. At the outgoing peering interface connecting provider O with provider T, the former's peering router re-marks AF21 traffic to AF31. The domain internal PHB of provider T that meets the requirement of the Diffserv-Intercon Assured Elastic Treatment Aggregate is from the AF2x PHB group. Hence, AF31 traffic received at the interconnection with provider T is re-marked to AF21 by the peering router of domain T, and domain T has chosen to use MPLS TC value 2 for this aggregate. At the penultimate MPLS node, the top MPLS label is removed and exposes the IP header marked by the DSCP that has been set at the network ingress. The peering router connecting domain T with domain 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's DSCP to be re-marked to AF31. The peering router of domain F classifies the packet for domain-F-internal PHB AF11, as this is the PHB with properties matching the Diffserv-Intercon Assured Elastic Treatment Aggregate.
提供商只需要部署内部DSCP与Diffserv Intercon DSCP之间的映射，这样他们就可以使用所需的PHB交换流量。在该示例中，提供者O已确定其内部类AF21的属性最好由Diffserv Intercon保证弹性处理聚合PHB AF31来满足。在连接提供商O和提供商T的传出对等接口处，前者的对等路由器将AF21流量重新标记为AF31。满足Diffserv Intercon Assured Elastic Treatment聚合要求的提供商T的域内部PHB来自AF2x PHB组。因此，域T的对等路由器将在与提供商T的互连处接收的AF31通信量重新标记为AF21，并且域T已选择将MPLS TC值2用于该聚合。在倒数第二个MPLS节点，移除顶部MPLS标签，并公开由网络入口处设置的DSCP标记的IP头。连接域T和域F的对等路由器通过其域T-内部DSCP AF21对数据包进行分类。当数据包离开域F接口上的域T时，这将导致数据包的DSCP被重新标记为AF31。域F的对等路由器对域F-内部PHB AF11的数据包进行分类，因为这是具有与Diffserv Intercon Assured弹性处理聚合匹配的属性的PHB。
This example can be extended. The figure shows provider W using CS2 for traffic that corresponds to Diffserv-Intercon Assured Elastic Treatment Aggregate PHB AF31; that traffic is mapped to AF31 at the Diffserv-Intercon interconnection to provider T. In addition, suppose that provider O supports a PHB marked by AF22, and this PHB is supposed to obtain Diffserv transport within provider T's domain. Then provider O will re-mark it with DSCP AF32 for interconnection to provider T.
这个例子可以扩展。该图显示提供商W使用CS2处理与Diffserv Intercon Assured Elastic处理聚合PHB AF31相对应的流量；该流量在与提供商T的Diffserv Intercon互连处映射到AF31。此外，假设提供商O支持由AF22标记的PHB，并且该PHB应在提供商T的域内获得Diffserv传输。然后，提供商O将使用DSCP AF32重新标记它，以便与提供商T互连。
Finally, suppose that provider W supports CS3 for internal use only. Then no Diffserv-Intercon DSCP mapping needs to be configured at the peering router. Traffic, sent by provider W to provider T marked by CS3 due to a misconfiguration may be re-marked to CS0 by provider T.
最后，假设提供者W仅支持内部使用的CS3。然后，不需要在对等路由器上配置Diffserv Intercon DSCP映射。由于配置错误，由提供商W发送到由CS3标记的提供商T的流量可能由提供商T重新标记为CS0。
This section briefly discusses end-to-end Diffserv approaches related to the Uniform, Pipe, and Short Pipe Model tunnels [RFC2983] [RFC3270] when used edge-to-edge in a network.
本节简要讨论在网络中边对边使用时，与统一、管道和短管模型隧道[RFC2983][RFC3270]相关的端到端区分服务方法。
o With the Uniform Model, neither the DSCP nor the PHB change. This implies that a network management packet received with a CS6 DSCP would be forwarded with an MPLS TC corresponding to CS6. The Uniform Model is outside the scope of this document.
o 在统一模型下，DSCP和PHB都没有变化。这意味着使用CS6 DSCP接收的网络管理数据包将使用对应于CS6的MPLS TC转发。统一模型不在本文件范围内。
o With the Pipe Model, the inner tunnel DSCP remains unchanged, but an outer tunnel DSCP and the PHB could change. For example, a packet received with a (network-specific) CS1 DSCP would be transported by a Default PHB and, if MPLS is applicable, forwarded with an MPLS TC corresponding to the Default PHB. The CS1 DSCP is not rewritten. Transport of a large variety (much greater than four) DSCPs may be required across an interconnected network operating MPLS Short Pipe Model transport for IP traffic. In that case, a tunnel based on the Pipe Model is among the possible approaches. The Pipe Model is outside the scope of this document.
o 使用管道模型时，内部隧道DSCP保持不变，但外部隧道DSCP和PHB可能会发生变化。例如，使用（特定于网络的）CS1 DSCP接收的分组将由默认PHB传输，并且如果MPLS适用，则使用与默认PHB对应的MPLS TC转发。CS1 DSCP不会被重写。可能需要在互联网络上传输多种（远远超过四种）DSCP，该互联网络运行用于IP流量的MPLS短管模型传输。在这种情况下，基于管道模型的隧道是可能的方法之一。管道模型不在本文档的范围内。
o With the Short Pipe Model, the DSCP likely changes, and the PHB might change. This document describes a method to simplify Diffserv network interconnection when a DSCP rewrite can't be avoided.
o 对于短管模型，DSCP可能会发生变化，而PHB可能会发生变化。本文档描述了在无法避免DSCP重写时简化Diffserv网络互连的方法。
4.3. Treatment of Network Control Traffic at Carrier Interconnection Interfaces
4.3. 运营商互连接口处网络控制流量的处理
As specified in Section 3.2 of RFC 4594, NC traffic marked by CS6 is expected at some interconnection interfaces. This document does not change RFC 4594 but observes that network control traffic received at a network ingress is generally different from network control traffic within a network that is the primary use of CS6 envisioned by RFC 4594. A specific example is that some CS6 traffic exchanged across carrier interconnections is terminated at the network ingress node, e.g., when BGP is used between the two routers on opposite ends of an interconnection link; in this case, the operators would enter into a bilateral agreement to use CS6 for that BGP traffic.
按照RFC 4594第3.2节的规定，在某些互连接口处，预期会出现CS6标记的NC通信量。本文件不改变RFC 4594，但观察到在网络入口接收的网络控制流量通常不同于网络内的网络控制流量，该网络是RFC 4594设想的CS6的主要用途。一个具体示例是，例如，当在互连链路的相对端上的两个路由器之间使用BGP时，跨载波互连交换的一些CS6业务在网络入口节点处终止；在这种情况下，运营商将签订双边协议，将CS6用于BGP流量。
The end-to-end discussion in Section 4.2 is generally inapplicable to network control traffic -- network control traffic is generally intended to control a network, not be transported between networks. One exception is that network control traffic makes sense for a purchased transit agreement, and preservation of the CS6 DSCP marking for network control traffic that is transited is reasonable in some cases, although it is generally inappropriate to use CS6 for forwarding that traffic within the network that provides transit. Use of an IP tunnel is suggested in order to conceal the CS6 markings on transiting network control traffic from the network that provides the transit. In this case, the Pipe Model for Diffserv tunneling is used.
第4.2节中的端到端讨论通常不适用于网络控制流量——网络控制流量通常用于控制网络，而不是在网络之间传输。一个例外是，网络控制流量对于购买的传输协议是有意义的，在某些情况下，为传输的网络控制流量保留CS6 DSCP标记是合理的，尽管通常不适合在提供传输的网络内使用CS6转发该流量。建议使用IP隧道，以隐藏提供传输的网络传输网络控制流量上的CS6标记。在这种情况下，使用了Diffserv隧道的管道模型。
If the MPLS Short Pipe Model is deployed for unencapsulated IPv4 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 the provider's own network.
如果为未封装的IPv4流量部署MPLS短管模型，则IP网络提供商应限制对CS6和CS7 DSCP的访问，以便它们仅用于提供商自己网络的网络控制流量。
Interconnecting carriers should specify treatment of CS6-marked traffic received at a carrier interconnection that is to be forwarded beyond the ingress node. An SLA covering the following cases is recommended when a provider wishes to send CS6-marked traffic across an interconnection link and that traffic's destination is beyond the interconnected ingress node:
互连运营商应指定在将转发到入口节点之外的运营商互连处接收的CS6标记流量的处理。当提供商希望通过互连链路发送CS6标记的通信量，且通信量的目的地超出互连入口节点时，建议使用涵盖以下情况的SLA：
o classification of traffic that is network control traffic for both domains. This traffic should be classified and marked for the CS6 DSCP.
o 两个域的网络控制流量的流量分类。应针对CS6 DSCP对该流量进行分类和标记。
o classification of traffic that is network control traffic for the sending domain only. This traffic should be forwarded with a PHB that is appropriate for transiting NC service class traffic [RFC4594] in the receiving domain, e.g., AF31 as specified by this document. As an example, GSMA IR.34 recommends an Interactive class / AF31 to carry SIP and DIAMETER traffic. While this is service control traffic of high importance to interconnected Mobile Network Operators, it is certainly not network control traffic for a fixed network providing transit among such operators and hence should not receive CS6 treatment in such a transit network.
o 仅为发送域的网络控制流量的流量分类。该流量应通过PHB转发，PHB适用于在接收域中传输NC服务类流量[RFC4594]，如本文件规定的AF31。例如，GSMA IR.34建议使用交互式类/AF31来承载SIP和DIAMETER流量。虽然这是对互连移动网络运营商非常重要的服务控制流量，但它肯定不是在此类运营商之间提供中转的固定网络的网络控制流量，因此不应在此类中转网络中接受CS6处理。
o any other CS6-marked traffic should be re-marked or dropped.
o 应重新标记或丢弃任何其他CS6标记的通信量。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
The DSCP field in the IP header can expose additional traffic classification information at network interconnections by comparison to the use of a zero DSCP for all interconnect traffic. If traffic classification information is sensitive, the DSCP field could be re-marked to zero to hide the classification as a countermeasure, at the cost of loss of Diffserv information and differentiated traffic handling on the interconnect and subsequent networks. When AF PHBs are used, any such re-marking should respect AF PHB group boundaries as further discussed at the end of Section 4.
与对所有互连流量使用零DSCP相比，IP报头中的DSCP字段可以在网络互连处公开额外的流量分类信息。如果流量分类信息是敏感的，DSCP字段可以重新标记为零，以隐藏作为对策的分类，代价是在互连和后续网络上丢失区分服务信息和区分流量处理。当使用AF PHB时，任何此类重新标记应遵守第4节末尾进一步讨论的AF PHB组边界。
This document does not introduce new features; it describes how to use existing ones. The Diffserv security considerations in [RFC2475] and [RFC4594] apply.
本文档不介绍新功能；它描述了如何使用现有的。[RFC2475]和[RFC4594]中的区分服务安全注意事项适用。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 2474，DOI 10.17487/RFC2474，1998年12月<http://www.rfc-editor.org/info/rfc2474>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/RFC2597, June 1999, <http://www.rfc-editor.org/info/rfc2597>.
[RFC2597]Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保付PHB集团”，RFC 2597，DOI 10.17487/RFC2597，1999年6月<http://www.rfc-editor.org/info/rfc2597>.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, <http://www.rfc-editor.org/info/rfc3246>.
[RFC3246]Davie，B.，Charny，A.，Bennet，J.，Benson，K.，Le Boudec，J.，Courtney，W.，Davari，S.，Firoiu，V.，和D.Stiliadis，“快速转发PHB（每跳行为）”，RFC 3246，DOI 10.17487/RFC3246，2002年3月<http://www.rfc-editor.org/info/rfc3246>.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, <http://www.rfc-editor.org/info/rfc3270>.
[RFC3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 3270，DOI 10.17487/RFC3270，2002年5月<http://www.rfc-editor.org/info/rfc3270>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008, <http://www.rfc-editor.org/info/rfc5129>.
[RFC5129]Davie，B.，Briscoe，B.，和J.Tay，“MPLS中的显式拥塞标记”，RFC 5129，DOI 10.17487/RFC5129，2008年1月<http://www.rfc-editor.org/info/rfc5129>.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, DOI 10.17487/RFC5865, May 2010, <http://www.rfc-editor.org/info/rfc5865>.
[RFC5865]Baker，F.，Polk，J.，和M.Dolly，“容量允许流量的差异化服务代码点（DSCP）”，RFC 5865，DOI 10.17487/RFC5865，2010年5月<http://www.rfc-editor.org/info/rfc5865>.
[BGP-INTERCONNECTION] Knoll, T., "BGP Class of Service Interconnection", Work in Progress, draft-knoll-idr-cos-interconnect-17, November 2016.
[BGP-INTERCONNECTION]Knoll，T.，“BGP服务类互连”，正在进行的工作，草稿-Knoll-idr-cos-interconnect-172016年11月。
[IR.34] GSMA, "Guidelines for IPX Provider networks (Previously Inter-Service Provider IP Backbone Guidelines)", Official Document IR.34, Version 11.0, November 2014, <http://www.gsma.com/newsroom/wp-content/uploads/ IR.34-v11.0.pdf>.
[IR.34]GSMA，“IPX提供商网络指南（以前为服务提供商IP主干网指南）”，官方文件IR.34，版本11.0，2014年11月<http://www.gsma.com/newsroom/wp-content/uploads/ IR.34-v11.0.pdf>。
[MEF23.1] MEF, "Implementation Agreement MEF 23.1: Carrier Ethernet Class of Service - Phase 2", MEF 23.1, January 2012, <http://metroethernetforum.org/PDF_Documents/ technical-specifications/MEF_23.1.pdf>.
[MEF23.1]MEF，“实施协议MEF 23.1：运营商以太网服务类别-第2阶段”，MEF 23.12012年1月<http://metroethernetforum.org/PDF_Documents/ 技术规范/MEF_23.1.pdf>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 2475，DOI 10.17487/RFC2475，1998年12月<http://www.rfc-editor.org/info/rfc2475>.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, <http://www.rfc-editor.org/info/rfc2983>.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 2983，DOI 10.17487/RFC2983，2000年10月<http://www.rfc-editor.org/info/rfc2983>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, DOI 10.17487/RFC3662, December 2003, <http://www.rfc-editor.org/info/rfc3662>.
[RFC3662]Bless，R.，Nichols，K.和K.Wehrle，“区分服务的低域行为（PDB）”，RFC 3662，DOI 10.17487/RFC3662，2003年12月<http://www.rfc-editor.org/info/rfc3662>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <http://www.rfc-editor.org/info/rfc4594>.
[RFC4594]Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 4594，DOI 10.17487/RFC4594，2006年8月<http://www.rfc-editor.org/info/rfc4594>.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, February 2008, <http://www.rfc-editor.org/info/rfc5127>.
[RFC5127]Chan，K.，Babiarz，J.和F.Baker，“区分服务类的聚合”，RFC 5127，DOI 10.17487/RFC5127，2008年2月<http://www.rfc-editor.org/info/rfc5127>.
[RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider-to-Provider Agreements for Internet-Scale Quality of Service (QoS)", RFC 5160, DOI 10.17487/RFC5160, March 2008, <http://www.rfc-editor.org/info/rfc5160>.
[RFC5160]Levis，P.和M.Boucadair，“互联网规模服务质量（QoS）提供商对提供商协议的考虑”，RFC 5160，DOI 10.17487/RFC5160，2008年3月<http://www.rfc-editor.org/info/rfc5160>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <http://www.rfc-editor.org/info/rfc7657>.
[RFC7657]Black，D.，Ed.和P.Jones，“区分服务（Diffserv）和实时通信”，RFC 7657，DOI 10.17487/RFC7657，2015年11月<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.
[SLA-EXCHANGE]Shah，S.，Patel，K.，Bajaj，S.，Tomotaki，L.，和M.Boucadair，“域间SLA交换属性”，正在进行的工作，草案-ietf-idr-SLA-EXCHANGE-10，2017年1月。
[Y.1566] ITU-T, "Quality of service mapping and interconnection between Ethernet, Internet protocol and multiprotocol label switching networks", ITU-T Recommendation Y.1566, July 2012, <http://www.itu.int/rec/T-REC-Y.1566-201207-I/en>.
[Y.1566]ITU-T，“以太网、互联网协议和多协议标签交换网络之间的服务质量映射和互连”，ITU-T建议Y.1566，2012年7月<http://www.itu.int/rec/T-REC-Y.1566-201207-I/en>.
The MPLS Short Pipe Model (or penultimate hop label popping) is widely deployed in carrier networks. If unencapsulated IP traffic is transported using MPLS Short Pipe, IP headers appear inside the last section of the MPLS domain. This impacts the number of PHBs and DSCPs that a network provider can reasonably support. See Figure 2 for an example.
MPLS短管模型（或倒数第二跳标签弹出）广泛部署在运营商网络中。如果使用MPLS短管传输未封装的IP流量，则IP报头将显示在MPLS域的最后一部分中。这会影响网络提供商可以合理支持的PHB和DSCP的数量。有关示例，请参见图2。
For encapsulated IP traffic, only the outer tunnel header is relevant for forwarding. If the tunnel does not terminate within the MPLS network section, only the outer tunnel DSCP is involved, as the inner DSCP does not affect forwarding behavior; in this case, all DSCPs could be used in the inner IP header without affecting network behavior based on the outer MPLS header. Here, the Pipe Model applies.
对于封装的IP流量，只有外部隧道报头与转发相关。如果隧道不在MPLS网络段内终止，则只涉及外部隧道DSCP，因为内部DSCP不影响转发行为；在这种情况下，所有DSCP都可以在内部IP报头中使用，而不会影响基于外部MPLS报头的网络行为。此处，管道模型适用。
Layer 2 and Layer 3 VPN traffic all use an additional MPLS label; in this case, the MPLS tunnel follows the Pipe Model. Classification and queuing within an MPLS network is always based on an MPLS label, as opposed to the outer IP header.
第2层和第3层VPN流量都使用额外的MPLS标签；在这种情况下，MPLS隧道遵循管道模型。MPLS网络中的分类和排队始终基于MPLS标签，而不是外部IP报头。
Carriers often select PHBs and DSCPs without regard to interconnection. As a result, PHBs and DSCPs typically differ between network carriers. With the exception of best-effort traffic, a DSCP change should be expected at an interconnection at least for unencapsulated IP traffic, even if the PHB is suitably mapped by the carriers involved.
运营商通常选择PHB和DSCP，而不考虑互连。因此，PHB和DSCP通常在网络运营商之间有所不同。除了尽力而为的通信量外，至少对于未封装的IP通信量，应在互连处预期DSCP变化，即使PHB由相关的运营商适当映射。
Although RFC 3270 suggests that the Short Pipe Model is only applicable to VPNs, current networks also use it to transport non-tunneled IPv4 traffic. This is shown in Figure 2 where Diffserv-Intercon is not used, resulting in exposure of the internal DSCPs of the upstream network to the downstream network across the interconnection.
尽管RFC 3270建议短管模型仅适用于VPN，但当前网络也使用它来传输非隧道IPv4流量。这如图2所示，其中未使用Diffserv Intercon，导致上游网络的内部DSCP通过互连暴露给下游网络。
|
\|/ IPv4, DSCP_send
V
|
Peering Router
|
\|/ IPv4, DSCP_send
V
|
MPLS Edge Router
| Mark MPLS Label, TC_internal
\|/ Re-mark DSCP to
V (Inner: IPv4, DSCP_d)
|
MPLS Core Router (penultimate hop label popping)
| \
| IPv4, DSCP_d | The DSCP needs to be in network-
| ^^^^^^^^| internal Diffserv context. The Core
\|/ > Router may require or enforce
V | that. The Edge Router may wrongly
| | classify, if the DSCP is not in
| / network-internal Diffserv context.
MPLS Edge Router
| \ Traffic leaves the network marked
\|/ IPv4, DSCP_d | with the network-internal
V > DSCP_d that must be dealt with
| | by the next network (downstream).
| /
Peer Router
| Re-mark DSCP to
\|/ IPv4, DSCP_send
V
|
|
\|/ IPv4, DSCP_send
V
|
Peering Router
|
\|/ IPv4, DSCP_send
V
|
MPLS Edge Router
| Mark MPLS Label, TC_internal
\|/ Re-mark DSCP to
V (Inner: IPv4, DSCP_d)
|
MPLS Core Router (penultimate hop label popping)
| \
| IPv4, DSCP_d | The DSCP needs to be in network-
| ^^^^^^^^| internal Diffserv context. The Core
\|/ > Router may require or enforce
V | that. The Edge Router may wrongly
| | classify, if the DSCP is not in
| / network-internal Diffserv context.
MPLS Edge Router
| \ Traffic leaves the network marked
\|/ IPv4, DSCP_d | with the network-internal
V > DSCP_d that must be dealt with
| | by the next network (downstream).
| /
Peer Router
| Re-mark DSCP to
\|/ IPv4, DSCP_send
V
|
Figure 2: Short Pipe Model / Penultimate Hop Popping Example
图2：短管模型/倒数第二跳弹出示例
The packet's IP DSCP must be in a well-understood Diffserv context for schedulers and classifiers on the interfaces of the ultimate MPLS link (last link traversed before leaving the network). The necessary Diffserv context is network-internal, and a network operating in this mode enforces DSCP usage in order to obtain robust differentiated forwarding behavior.
对于最终MPLS链路（离开网络前经过的最后一条链路）接口上的调度器和分类器，数据包的IP DSCP必须处于一个易于理解的Diffserv上下文中。必要的区分服务上下文是网络内部上下文，在此模式下运行的网络强制使用DSCP以获得健壮的区分转发行为。
Without Diffserv-Intercon treatment, the traffic is likely to leave each network marked with network-internal DSCP. DSCP_send in the 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.
如果没有Diffserv Intercon处理，流量很可能会离开标有网络内部DSCP的每个网络。上图中的DSCP_发送必须在入口MPLS边缘路由器处重新标记为第一个网络的Diffserv方案，在示例中标记为DSCP_d。
For that reason, the traffic leaves this domain marked by the network-internal DSCP_d. This structure requires that every carrier deploys per-peer PHB and DSCP mapping schemes.
因此，通信量离开这个由网络内部DSCP\U d标记的域。这种结构要求每个运营商部署每个对等PHB和DSCP映射方案。
If Diffserv-Intercon is applied, DSCPs for traffic transiting the domain can be mapped from and remapped to an original DSCP. This is 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 its direct customers.
如果应用了Diffserv Intercon，则可以从原始DSCP映射并重新映射通过域的流量的DSCP。这如图3所示。内部通信可继续使用内部DSCP（如DSCP），也可在运营商与其直接客户之间使用。
Internal Router
|
| Outer Header
\|/ IPv4, DSCP_send
V
|
Peering Router
| Re-mark DSCP to
\|/ IPv4, DSCP_ds-int Diffserv-Intercon DSCP and PHB
V
|
MPLS Edge Router
|
| Mark MPLS Label, TC_internal
\|/ Re-mark DSCP to
V (Inner: IPv4, DSCP_d) Domain Internal DSCP for
| the PHB
MPLS Core Router (penultimate hop label popping)
|
| IPv4, DSCP_d
| ^^^^^^
\|/
V
|
|
MPLS Edge Router--------------------+
| |
\|/ Re-mark DSCP to \|/ IPv4, DSCP_d
V IPv4, DSCP_ds-int V
| |
| |
Peer Router Domain Internal Broadband
| Access Router
\|/ Re-mark DSCP to \|/
V IPv4, DSCP_send V IPv4, DSCP_d
| |
Internal Router
|
| Outer Header
\|/ IPv4, DSCP_send
V
|
Peering Router
| Re-mark DSCP to
\|/ IPv4, DSCP_ds-int Diffserv-Intercon DSCP and PHB
V
|
MPLS Edge Router
|
| Mark MPLS Label, TC_internal
\|/ Re-mark DSCP to
V (Inner: IPv4, DSCP_d) Domain Internal DSCP for
| the PHB
MPLS Core Router (penultimate hop label popping)
|
| IPv4, DSCP_d
| ^^^^^^
\|/
V
|
|
MPLS Edge Router--------------------+
| |
\|/ Re-mark DSCP to \|/ IPv4, DSCP_d
V IPv4, DSCP_ds-int V
| |
| |
Peer Router Domain Internal Broadband
| Access Router
\|/ Re-mark DSCP to \|/
V IPv4, DSCP_send V IPv4, DSCP_d
| |
Figure 3: Short Pipe Model Example with Diffserv-Intercon
图3:Diffserv Intercon的短管模型示例
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.
Bob Briscoe和Gorry Fairhurst审查了该规范，并提供了丰富的反馈。Brian Carpenter、Fred Baker、Al Morton和Sebastien Jobert讨论了规范并帮助改进了规范。穆罕默德·布卡达尔（Mohamed Boucadair）和托马斯·诺尔（Thomas Knoll）通过增加对相关工作的认识而有所帮助。James Polk在IETF 89期间的讨论有助于改进本规范与RFCs 4594和5127之间关系的文本。
Authors' Addresses
作者地址
Ruediger Geib (editor) Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt 64295 Germany
Ruediger Geib（编辑）德国电信海因里希赫兹街3-7号达姆施塔特64295
Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de
Phone: +49 6151 5812747
Email: Ruediger.Geib@telekom.de
David L. Black Dell EMC 176 South Street Hopkinton, MA United States of America
David L.Black Dell EMC美国马萨诸塞州霍普金顿南街176号
Phone: +1 (508) 293-7953
Email: david.black@dell.com
Phone: +1 (508) 293-7953
Email: david.black@dell.com