Network Working Group D. Black
Request for Comments: 2983 EMC Corporation
Category: Informational October 2000
Network Working Group D. Black
Request for Comments: 2983 EMC Corporation
Category: Informational October 2000
Differentiated Services and Tunnels
差异化服务和隧道
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document considers the interaction of Differentiated Services (diffserv) (RFC 2474, RFC 2475) with IP tunnels of various forms. The discussion of tunnels in the diffserv architecture (RFC 2475) provides insufficient guidance to tunnel designers and implementers. This document describes two conceptual models for the interaction of diffserv with Internet Protocol (IP) tunnels and employs them to explore the resulting configurations and combinations of functionality. An important consideration is how and where it is appropriate to perform diffserv traffic conditioning in the presence of tunnel encapsulation and decapsulation. A few simple mechanisms are also proposed that limit the complexity that tunnels would otherwise add to the diffserv traffic conditioning model. Security considerations for IPSec tunnels limit the possible functionality in some circumstances.
本文档考虑了区分服务（diffserv）（RFC 2474、RFC 2475）与各种形式的IP隧道的交互。对diffserv体系结构（RFC 2475）中隧道的讨论对隧道设计者和实现者的指导不足。本文档描述了diffserv与Internet协议（IP）隧道交互的两个概念模型，并利用它们来探索最终的配置和功能组合。一个重要的考虑因素是，在隧道封装和去封装的情况下，如何以及在何处执行区分服务流量调节。还提出了一些简单的机制，以限制隧道可能增加到diffserv流量调节模型中的复杂性。IPSec隧道的安全注意事项在某些情况下限制了可能的功能。
An IP tunnel encapsulates IP traffic in another IP header as it passes through the tunnel; the presence of these two IP headers is a defining characteristic of IP tunnels, although there may be additional headers inserted between the two IP headers. The inner IP header is that of the original traffic; an outer IP header is attached and detached at tunnel endpoints. In general, intermediate network nodes between tunnel endpoints operate solely on the outer IP header, and hence diffserv-capable intermediate nodes access and modify only the DSCP field in the outer IP header. The terms "tunnel" and "IP tunnel" are used interchangeably in this document. For simplicity, this document does not consider tunnels other than IP tunnels (i.e., for which there is no encapsulating IP header), such
IP隧道在另一个IP报头中封装IP流量，因为它通过隧道；这两个IP报头的存在是IP隧道的一个定义特征，尽管在这两个IP报头之间可能插入其他报头。内部IP报头是原始流量的报头；在隧道端点处附加和分离外部IP标头。通常，隧道端点之间的中间网络节点仅在外部IP报头上运行，因此，支持区分服务的中间节点仅访问和修改外部IP报头中的DSCP字段。术语“隧道”和“IP隧道”在本文件中互换使用。为了简单起见，该文档不考虑IP隧道以外的隧道（即，其中没有封装IP报头）。
as MPLS paths and "tunnels" formed by encapsulation in layer 2 (link) headers, although the conceptual models and approach described here may be useful in understanding the interaction of diffserv with such tunnels.
作为通过封装在第2层（链路）报头中形成的MPLS路径和“隧道”，尽管这里描述的概念模型和方法可能有助于理解区分服务与此类隧道的交互。
This analysis considers tunnels to be unidirectional; bi-directional tunnels are considered to be composed of two unidirectional tunnels carrying traffic in opposite directions between the same tunnel endpoints. A tunnel consists of an ingress where traffic enters the tunnel and is encapsulated by the addition of the outer IP header, an egress where traffic exits the tunnel and is decapsulated by the removal of the outer IP header, and intermediate nodes through which tunneled traffic passes between the ingress and egress. This document does not make any assumptions about routing and forwarding of tunnel traffic, and in particular assumes neither the presence nor the absence of route pinning in any form.
该分析认为隧道是单向的；双向隧道被认为是由两个单向隧道组成，在相同的隧道端点之间承载相反方向的交通。隧道包括一个入口，其中流量进入隧道并通过添加外部IP报头进行封装；一个出口，其中流量退出隧道并通过移除外部IP报头进行去封装；以及中间节点，隧道流量通过该节点在入口和出口之间通过。本文件不对隧道交通的路由和转发做出任何假设，尤其是假设不存在任何形式的路由固定。
Tunnels range in complexity from simple IP-in-IP tunnels [RFC 2003] to more complex multi-protocol tunnels, such as IP in PPP in L2TP in IPSec transport mode [RFC 1661, RFC 2401, RFC 2661]. The most general tunnel configuration is one in which the tunnel is not end-to-end, i.e., the ingress and egress nodes are not the source and destination nodes for traffic carried by the tunnel; such a tunnel may carry traffic with multiple sources and destinations. If the ingress node is the end-to-end source of all traffic in the tunnel, the result is a simplified configuration to which much of the analysis and guidance in this document are applicable, and likewise if the egress node is the end-to-end destination.
隧道的复杂性从简单的IP-in-IP隧道[RFC 2003]到更复杂的多协议隧道，如IPSec传输模式下L2TP中PPP中的IP[RFC 1661、RFC 2401、RFC 2661]。最一般的隧道配置是其中隧道不是端到端的，即入口和出口节点不是隧道承载的业务的源节点和目的节点；此类隧道可承载多个来源和目的地的交通。如果入口节点是隧道中所有流量的端到端源，则结果是简化配置，本文件中的大部分分析和指导适用于此配置，同样，如果出口节点是端到端目的地。
A primary concern for differentiated services is the use of the Differentiated Services Code Point (DSCP) in the IP header [RFC 2474, RFC 2475]. The diffserv architecture permits intermediate nodes to examine and change the value of the DSCP, which may result in the DSCP value in the outer IP header being modified between tunnel ingress and egress. When a tunnel is not end-to-end, there are circumstances in which it may be desirable to propagate the DSCP and/or some of the information that it contains to the outer IP header on ingress and/or back to inner IP header on egress. The current situation facing tunnel implementers is that [RFC 2475] offers incomplete guidance. Guideline G.7 in Section 3 is an example, as some PHB specifications have followed it by explicitly specifying the PHBs that may be used in the outer IP header for tunneled traffic. This is overly restrictive; for example, if a specification requires that the same PHB be used in both the inner and outer IP headers, traffic conforming to that specification cannot be tunneled across domains or networks that do not support that PHB.
区分服务的一个主要问题是在IP报头中使用区分服务代码点（DSCP）[RFC 2474，RFC 2475]。diffserv体系结构允许中间节点检查和更改DSCP的值，这可能导致在隧道入口和出口之间修改外部IP报头中的DSCP值。当隧道不是端到端时，在某些情况下，可能需要将DSCP和/或其包含的一些信息传播到入口的外部IP报头和/或出口的内部IP报头。隧道实施者面临的当前情况是[RFC 2475]提供的指导不完整。第3节中的指南G.7是一个示例，因为一些PHB规范随后明确规定了可用于隧道通信的外部IP报头中的PHB。这是过分的限制；例如，如果规范要求在内部和外部IP报头中使用相同的PHB，则符合该规范的流量不能通过不支持该PHB的域或网络进行隧道传输。
A more flexible approach that should be used instead is to describe the behavioral properties of a PHB that are important to preserve when traffic is tunneled and allow the outer IP header to be marked in any fashion that is sufficient to preserve those properties.
相反，应该使用更灵活的方法来描述PHB的行为属性，这些属性在对流量进行隧道传输时非常重要，并允许以足以保留这些属性的任何方式标记外部IP报头。
This document proposes an approach in which traffic conditioning is performed in series with tunnel ingress or egress processing, rather than in parallel. This approach does not create any additional paths that transmit information across a tunnel endpoint, as all diffserv information is contained in the DSCPs in the IP headers. The IPSec architecture [RFC 2401] requires that this be the case to preserve security properties at the egress of IPSec tunnels, but this approach also avoids complicating diffserv traffic conditioning blocks by introducing out-of-band inputs. A consequence of this approach is that the last sentence of Guideline G.7 in Section 3 of [RFC 2475] becomes moot because there are no tunnel egress diffserv components that have access to both the inner and outer DSCPs.
本文件提出了一种方法，其中交通调节与隧道入口或出口处理串联执行，而不是并行执行。这种方法不会创建任何通过隧道端点传输信息的附加路径，因为所有区分服务信息都包含在IP报头中的DSCP中。IPSec体系结构[RFC 2401]要求在IPSec隧道出口处保留安全属性，但这种方法还通过引入带外输入避免使区分服务流量调节块复杂化。这种方法的一个结果是，[RFC 2475]第3节中指南G.7的最后一句变得没有意义，因为没有隧道出口区分服务组件可以访问内部和外部DSCP。
An additional advantage of this traffic conditioning approach is that it places no additional restrictions on the positioning of diffserv domain boundaries with respect to traffic conditioning and tunnel encapsulation/decapsulation components. An interesting class of configurations involves a diffserv domain boundary that passes through (i.e., divides) a network node; such a boundary can be split to create a DMZ-like region between the domains that contains the tunnel encapsulation or decapsulation processing. Diffserv traffic conditioning is not appropriate for such a DMZ-like region, as traffic conditioning is part of the operation and management of diffserv domains.
这种流量调节方法的另一个优点是，它不会对与流量调节和隧道封装/去封装组件相关的区分服务域边界的定位施加额外的限制。一类有趣的配置涉及穿过（即划分）网络节点的diffserv域边界；这样的边界可以被分割以在包含隧道封装或去封装处理的域之间创建类似DMZ的区域。Diffserv流量调节不适用于此类类似DMZ的区域，因为流量调节是Diffserv域操作和管理的一部分。
This analysis introduces two conceptual traffic conditioning models for IP tunnels based on an initial discussion that assumes a fully diffserv-capable network. Configurations in which this is not the case are taken up in Section 3.2.
该分析介绍了IP隧道的两个概念性流量调节模型，基于假设具有完全区分服务能力的网络的初步讨论。第3.2节讨论了不属于这种情况的配置。
The first conceptual model is a uniform model that views IP tunnels as artifacts of the end to end path from a traffic conditioning standpoint; tunnels may be necessary mechanisms to get traffic to its destination(s), but have no significant impact on traffic conditioning. In this model, any packet has exactly one DS Field that is used for traffic conditioning at any point, namely the DS Field in the outermost IP header; any others are ignored. Implementations of this model copy the DSCP value to the outer IP header at encapsulation and copy the outer header's DSCP value to the
第一个概念模型是一个统一模型，从流量调节的角度将IP隧道视为端到端路径的工件；隧道可能是将交通运输到目的地的必要机制，但对交通调节没有显著影响。在该模型中，任何数据包都有一个DS字段，用于在任何点进行流量调节，即最外层IP报头中的DS字段；其他的都被忽略了。此模型的实现在封装时将DSCP值复制到外部IP报头，并将外部报头的DSCP值复制到外部IP报头
inner IP header at decapsulation. Use of this model allows IP tunnels to be configured without regard to diffserv domain boundaries because diffserv traffic conditioning functionality is not impacted by the presence of IP tunnels.
解除封装时的内部IP标头。使用此模型可以在不考虑区分服务域边界的情况下配置IP隧道，因为区分服务流量调节功能不受IP隧道的影响。
The second conceptual model is a pipe model that views an IP tunnel as hiding the nodes between its ingress and egress so that they do not participate fully in traffic conditioning. In this model, a tunnel egress node uses traffic conditioning information conveyed from the tunnel ingress by the DSCP value in the inner header, and ignores (i.e., discards) the DSCP value in the outer header. The pipe model cannot completely hide traffic conditioning within the tunnel, as the effects of dropping and shaping at intermediate tunnel nodes may be visible at the tunnel egress and beyond.
第二个概念模型是一个管道模型，它将IP隧道视为在其入口和出口之间隐藏节点，以便它们不完全参与流量调节。在此模型中，隧道出口节点使用由内部报头中的DSCP值从隧道入口传送的流量调节信息，并忽略（即丢弃）外部报头中的DSCP值。管道模型不能完全隐藏隧道内的交通状况，因为中间隧道节点处的下降和成形效应可能在隧道出口和出口处可见。
The pipe model has traffic conditioning consequences when the ingress and egress nodes are in different diffserv domains. In such a situation, the egress node must perform traffic conditioning to ensure that the traffic exiting the tunnel has DSCP values acceptable to the egress diffserv domain (see Section 6 of the diffserv architecture [RFC 2475]). An inter-domain TCA (Traffic Conditioning Agreement) between the diffserv domains containing the tunnel ingress and egress nodes may be used to reduce or eliminate egress traffic conditioning. Complete elimination of egress traffic conditioning requires that the diffserv domains at ingress and egress have compatible service provisioning policies for the tunneled traffic and support all of the PHB groups and DSCP values used for that traffic in a consistent fashion. Examples of this situation are provided by some virtual private network tunnels; it may be useful to view such tunnels as linking the diffserv domains at their endpoints into a diffserv region by making the tunnel endpoints virtually contiguous even though they may be physically separated by intermediate network nodes.
当入口和出口节点位于不同的区分服务域时，管道模型具有流量调节的结果。在这种情况下，出口节点必须执行流量调节，以确保离开隧道的流量具有出口区分服务域可接受的DSCP值（参见区分服务体系结构[RFC 2475]第6节）。包含隧道入口和出口节点的区分服务域之间的域间TCA（流量调节协议）可用于减少或消除出口流量调节。完全消除出口流量调节要求入口和出口处的diffserv域具有针对隧道流量的兼容服务提供策略，并以一致的方式支持用于该流量的所有PHB组和DSCP值。一些虚拟专用网络隧道提供了这种情况的示例；通过使隧道端点几乎连续（即使它们可能被中间网络节点物理上分开），将此类隧道视为将其端点处的区分服务域链接到区分服务区域，这可能是有用的。
The pipe model is also appropriate for situations in which the DSCP itself carries information through the tunnel. For example, if transit between two domains is obtained via a path that uses the EF PHB [RFC 2598], the drop precedence information in the AF PHB DSCP values [RFC 2597] will be lost unless something is done to preserve it; an IP tunnel is one possible preservation mechanism. A path that crosses one or more non-diffserv domains between its DS-capable endpoints may experience a similar information loss phenomenon if a tunnel is not used due to the limited set of DSCP codepoints that are compatible with such domains.
管道模型也适用于DSCP本身通过隧道传输信息的情况。例如，如果通过使用EF PHB[RFC 2598]的路径获得两个域之间的传输，则AF PHB DSCP值[RFC 2597]中的丢弃优先级信息将丢失，除非采取措施保留它；IP隧道是一种可能的保护机制。如果由于与这些域兼容的DSCP码点集有限而未使用隧道，则在其支持DS的端点之间跨越一个或多个非diffserv域的路径可能会遇到类似的信息丢失现象。
If only the tunnel egress node is DS-capable, [RFC 2475] requires the egress node to perform any edge traffic conditioning needed by the diffserv domain for tunneled traffic entering from outside the domain. If the egress node would not otherwise be a DS edge node, one way to meet this requirement is to perform edge traffic conditioning at an appropriate upstream DS edge node within the tunnel, and copy the DSCP value from the outer IP header to the inner IP header as part of tunnel decapsulation processing; this applies the uniform model to the portion of the tunnel within the egress node's diffserv domain. A second alternative is to discard the outer DSCP value as part of decapsulation processing, reducing the resulting traffic conditioning problem and requirements to those of an ordinary DS ingress node. This applies the pipe model to the portion of the tunnel within the egress node's diffserv domain and hence the adjacent upstream node for DSCP marking purposes is the tunnel ingress node, rather than the immediately upstream intermediate tunnel node.
如果只有隧道出口节点具有DS能力，[RFC 2475]要求出口节点执行diffserv域所需的任何边缘流量调节，以用于从域外部进入的隧道流量。如果出口节点不是DS边缘节点，则满足此要求的一种方法是在隧道内的适当上游DS边缘节点处执行边缘业务调节，并将DSCP值从外部IP报头复制到内部IP报头，作为隧道解封装处理的一部分；这将统一模型应用于出口节点的diffserv域内的隧道部分。第二种替代方案是丢弃外部DSCP值作为去封装处理的一部分，从而将产生的流量调节问题和要求降低到普通DS入口节点的流量调节问题和要求。这将管道模型应用于出口节点的diffserv域内的隧道部分，因此用于DSCP标记的相邻上游节点是隧道入口节点，而不是紧邻上游的中间隧道节点。
If only the tunnel ingress node is DS-capable, [RFC 2475] requires that traffic emerging from the tunnel be compatible with the network at the tunnel egress. If tunnel decapsulation processing discards the outer header's DSCP value without changing the inner header's DSCP value, the DS-capable tunnel ingress node is obligated to set the inner header's DSCP to a value compatible with the network at the tunnel egress. The value 0 (DSCP of 000000) is used for this purpose by a number of existing tunnel implementations. If the egress network implements IP precedence as specified in [RFC 791], then some or all of the eight class selector DSCP codepoints defined in [RFC 2474] may be usable. DSCP codepoints other than the class selectors are not generally suitable for this purpose, as correct operation would usually require diffserv functionality at the DS-incapable tunnel egress node.
如果只有隧道入口节点具有DS能力，[RFC 2475]要求从隧道流出的流量与隧道出口处的网络兼容。如果隧道解除封装处理丢弃外部报头的DSCP值而不更改内部报头的DSCP值，则支持DS的隧道入口节点有义务将内部报头的DSCP设置为与隧道出口处的网络兼容的值。值0（DSCP为000000）被许多现有的隧道实现用于此目的。如果出口网络实现[RFC 791]中规定的IP优先级，则[RFC 2474]中定义的八个类选择器DSCP码点中的部分或全部可能可用。除类选择器之外的DSCP码点通常不适合此目的，因为正确的操作通常需要DS通道出口节点处的diffserv功能。
As described in Section 3 above, this analysis is based on an approach in which diffserv functionality and/or out-of-band communication paths are not placed in parallel with tunnel encapsulation processing. This allows three possible locations for traffic conditioning with respect to tunnel encapsulation processing, as shown in the following diagram that depicts the flow of IP headers through tunnel encapsulation:
如上文第3节所述，该分析基于一种方法，其中区分服务功能和/或带外通信路径不与隧道封装处理并行放置。这允许在三个可能的位置进行有关隧道封装处理的流量调节，如下图所示，该图描述了IP报头通过隧道封装的流程：
+--------- [2 - Outer] -->>
/
/
>>---- [1 - Before] -------- Encapsulate ------ [3 - Inner] -->>
+--------- [2 - Outer] -->>
/
/
>>---- [1 - Before] -------- Encapsulate ------ [3 - Inner] -->>
Traffic conditioning at [1 - Before] is logically separate from the tunnel, as it is not impacted by the presence of tunnel encapsulation, and hence should be allowed by tunnel designs and specifications. Traffic conditioning at [2 - Outer] may interact with tunnel protocols that are sensitive to packet reordering; such tunnels may need to limit the functionality at [2 - Outer] as discussed further in Section 5.1. In the absence of reordering sensitivity, no additional restrictions should be necessary, although traffic conditioning at [2 - Outer] may be responsible for remarking traffic to be compatible with the next diffserv domain that the tunneled traffic enters.
[1-之前]的交通调节在逻辑上与隧道分开，因为它不受隧道封装的影响，因此隧道设计和规范应允许。[2-外部]处的流量调节可与对分组重新排序敏感的隧道协议交互；如第5.1节所述，此类隧道可能需要限制[2-外部]的功能。在没有重新排序敏感性的情况下，不需要额外的限制，尽管[2-外部]的流量调节可能负责将流量标记为与隧道流量进入的下一个diffserv域兼容。
In contrast, the [3 - Inner] location is difficult to utilize for traffic conditioning because it requires functionality that reaches inside the packet to operate on the inner IP header. This is impossible for IPSec tunnels and any other tunnels that are encrypted or employ cryptographic integrity checks. Hence traffic conditioning at [3 - Inner] can often only be performed as part of tunnel encapsulation processing, complicating both the encapsulation and traffic conditioning implementations. In many cases, the desired functionality can be achieved via a combination of traffic conditioners in the other two locations, both of which can be specified and implemented independently of tunnel encapsulation.
相反，[3-内部]位置很难用于流量调节，因为它需要到达数据包内部的功能才能在内部IP报头上操作。这对于IPSec隧道和任何其他加密或使用加密完整性检查的隧道来说是不可能的。因此，[3-内部]的流量调节通常只能作为隧道封装处理的一部分来执行，这使得封装和流量调节实现都变得复杂。在许多情况下，可以通过其他两个位置的流量调节器的组合来实现所需的功能，这两个位置都可以独立于隧道封装来指定和实现。
An exception for which traffic conditioning functionality is necessary at [3 - Inner] occurs when the DS-incapable tunnel egress discards the outer IP header as part of decapsulation processing, and hence the DSCP in the inner IP header must be compatible with the egress network. Setting the inner DSCP to 0 as part of encapsulation addresses most of these cases, and the class selector DCSP codepoint values are also useful for this purpose, as they are valid for networks that support IP precedence [RFC 791].
当DS通道出口在解封处理过程中丢弃外部IP报头时，出现[3-内部]需要流量调节功能的异常，因此内部IP报头中的DSCP必须与出口网络兼容。作为封装的一部分，将内部DSCP设置为0可以解决大多数情况，类选择器DCSP codepoint值也可用于此目的，因为它们对支持IP优先级的网络有效[RFC 791]。
The following table summarizes the achievable relationships among the before (B), outer (O), and inner (I) DSCP values and the corresponding locations of traffic conditioning logic.
下表总结了前（B）、外（O）和内（I）DSCP值与流量调节逻辑的相应位置之间可实现的关系。
Relationship Traffic Conditioning Location(s)
------------ --------------------------------
B = I = O No traffic conditioning required
B != I = O [1 - Before]
B = I != O [2 - Outer]
B = O != I Limited support as part of encapsulation:
I can be set to 000000 or possibly one of
the class selector code points.
B != I != O Some combination of the above three scenarios.
Relationship Traffic Conditioning Location(s)
------------ --------------------------------
B = I = O No traffic conditioning required
B != I = O [1 - Before]
B = I != O [2 - Outer]
B = O != I Limited support as part of encapsulation:
I can be set to 000000 or possibly one of
the class selector code points.
B != I != O Some combination of the above three scenarios.
A combination of [1 - Before] and [2 - Outer] is applicable to many cases covered by the last two lines of the table, and may be preferable to deploying functionality at [3 - Inner]. Traffic conditioning may still be required for purposes such as rate and burst control even if DSCP values are not changed.
[1-Before]和[2-Outer]的组合适用于表的最后两行所涵盖的许多情况，并且可能比在[3-Inner]部署功能更好。即使DSCP值未更改，出于速率和突发控制等目的，仍可能需要流量调节。
It may be necessary or desirable to limit the DS behavior aggregates that utilize an IP tunnel that is sensitive to packet reordering within the tunnel. The diffserv architecture allows packets to be reordered when they belong to behavior aggregates among which reordering is permitted; for example, reordering is allowed among behavior aggregates marked with different Class Selector DSCPs [RFC 2474]. IPSec [RFC 2401] and L2TP [RFC 2661] provide examples of tunnels that are sensitive to packet reordering. If IPSec's anti-replay support is configured, audit events are generated in response to packet reordering that exceeds certain levels, with the audit events indicating potential security issues. L2TP can be configured to restore the ingress ordering of packets at tunnel egress, not only undoing any differentiation based on reordering within the tunnel, but also negatively impacting the traffic (e.g., by increasing latency). The uniform model cannot be completely applied to such tunnels, as arbitrary mixing of traffic from different behavior aggregates can cause these undesirable interactions.
可能需要或期望限制使用对隧道内的分组重新排序敏感的IP隧道的DS行为聚合。当数据包属于允许重新排序的行为聚合时，diffserv体系结构允许数据包重新排序；例如，使用不同的类选择器DSCP[RFC 2474]标记的行为聚合之间允许重新排序。IPSec[RFC 2401]和L2TP[RFC 2661]提供了对数据包重新排序敏感的隧道示例。如果配置了IPSec的反重播支持，则会生成审核事件以响应超过特定级别的数据包重新排序，审核事件指示潜在的安全问题。L2TP可配置为在隧道出口处恢复数据包的入口顺序，不仅撤销基于隧道内重新排序的任何区分，而且还对流量产生负面影响（例如，通过增加延迟）。统一模型不能完全应用于此类隧道，因为来自不同行为聚集体的任意交通混合可能导致这些不希望的相互作用。
The simplest method of avoiding undesirable interactions of reordering with reordering-sensitive tunnel protocols and features is not to employ the reordering-sensitive protocols or features, but this is often not desirable or even possible. When such protocols or features are used, interactions can be avoided by ensuring that the aggregated flows through the tunnel are marked at [2 - Outer] to constitute a single ordered aggregate (i.e., the PHBs used share an ordering constraint that prevents packets from being reordered). Tunnel protocol specifications should indicate both whether and under what circumstances a tunnel should be restricted to a single ordered aggregate as well as the consequences of deviating from that restriction. For the IPSec and L2TP examples discussed above, the
避免重排序与重排序敏感隧道协议和特性之间的不良交互的最简单方法是不使用重排序敏感协议或特性，但这通常是不可取的，甚至是不可能的。当使用此类协议或功能时，可通过确保通过隧道的聚合流标记为[2-外部]以构成单个有序聚合来避免交互（即，所使用的PHB共享一个阻止数据包重新排序的排序约束）。隧道协议规范应说明隧道是否以及在何种情况下应限制为单个有序聚合，以及偏离该限制的后果。对于上面讨论的IPSec和L2TP示例
specifications should restrict each tunnel to a single ordered aggregate when protocol features sensitive to reordering are configured, and may adopt the approach of restricting all tunnels in order to avoid unexpected consequences of changes in protocol features or composition of tunneled traffic. Diffserv implementations should not attempt to look within such tunnels to provide reordering-based differentiation to the encapsulated microflows. If reordering-based differentiation is desired within such tunnels, multiple parallel tunnels between the same endpoints should be used. This enables reordering among packets in different tunnels to coexist with an absence of packet reordering within each individual tunnel. For IPSec and related security protocols, there is no cryptographic advantage to using a single tunnel for multiple ordered aggregates rather than multiple tunnels because any traffic analysis made possible by the use of multiple tunnels can also be performed based on the DSCPs in the outer headers of traffic in a single tunnel. In general, the additional resources required to support multiple tunnels (e.g., cryptographic contexts), and the impact of multiple tunnels on network management should be considered in determining whether and where to deploy them.
当配置对重新排序敏感的协议功能时，规范应将每个隧道限制为单个有序聚合，并可采用限制所有隧道的方法，以避免协议功能或隧道流量组成变化的意外后果。Diffserv实现不应该试图在这样的通道中寻找，以便为封装的微流提供基于重新排序的区分。如果在此类隧道内需要基于重新排序的差异，则应在相同端点之间使用多个并行隧道。这使得不同隧道中的数据包之间的重新排序能够共存，而每个隧道中都没有数据包重新排序。对于IPSec和相关安全协议，对于多个有序聚合而不是多个隧道使用单个隧道没有任何加密优势，因为使用多个隧道可能进行的任何流量分析也可以基于单个隧道中流量的外部报头中的DSCP来执行。一般来说，在确定是否以及在何处部署多个隧道时，应考虑支持多个隧道（例如，加密上下文）所需的额外资源，以及多个隧道对网络管理的影响。
The behavioral characteristics of a tunnel are an important consideration in determining what traffic should utilize the tunnel. This involves the service provisioning policies of all the participating domains, not just the PHBs and DSCPs marked on the traffic at [2 - Outer]. For example, while it is in general a bad idea to tunnel EF PHB traffic via a Default PHB tunnel, this can be acceptable if the EF traffic is the only traffic that utilizes the tunnel, and the tunnel is provisioned in a fashion adequate to preserve the behavioral characteristics required by the EF PHB.
隧道的行为特征是确定应使用隧道的交通量的重要考虑因素。这涉及所有参与域的服务提供策略，而不仅仅是[2-外部]流量上标记的PHB和DSCP。例如，虽然通过默认PHB隧道对EF PHB流量进行隧道传输通常是一个坏主意，但如果EF流量是唯一使用隧道的流量，并且隧道的供应方式足以保持EF PHB所需的行为特征，则这是可以接受的。
Service provisioning policies are responsible for preventing mismatches such as forwarding EF traffic via an inadequately provisioned Default tunnel. When multiple parallel tunnels with different behavioral characteristics are available, service provisioning policies are responsible for determining which flows should use which tunnels. Among the possibilities is a coarse version of the uniform tunnel model in which the inner DSCP value is used to select a tunnel that will forward the traffic using a behavioral aggregate that is compatible with the traffic's PHB.
服务提供策略负责防止不匹配，例如通过未充分提供的默认隧道转发EF流量。当具有不同行为特征的多个并行隧道可用时，服务提供策略负责确定哪些流应该使用哪些隧道。其中一种可能性是统一隧道模型的粗略版本，其中内部DSCP值用于选择一个隧道，该隧道将使用与交通PHB兼容的行为聚合转发交通。
As described in Section 3 above, this analysis is based on an approach in which diffserv functionality and/or out-of-band communication paths are not placed in parallel with tunnel
如上文第3节所述，该分析基于一种方法，其中区分服务功能和/或带外通信路径不与隧道并行放置
encapsulation processing. This allows three possible locations for traffic conditioners with respect to tunnel decapsulation processing, as shown in the following diagram that depicts the flow of IP headers through tunnel decapsulation:
封装处理。这允许流量调节器在三个可能的位置进行隧道去封装处理，如下图所示，该图描述了IP报头通过隧道去封装的流程：
>>----[5 - Outer]-------------+
\
\
>>----[4 - Inner] --------- Decapsulate ---- [6 - After] -->>
>>----[5 - Outer]-------------+
\
\
>>----[4 - Inner] --------- Decapsulate ---- [6 - After] -->>
Traffic conditioning at [5 - Outer] and [6 - After] is logically separate from the tunnel, as it is not impacted by the presence of tunnel decapsulation. Tunnel designs and specifications should allow diffserv traffic conditioning at these locations. Such conditioning can be viewed as independent of the tunnel, i.e., [5 - Outer] is traffic conditioning that takes place prior to tunnel egress, and [6 - After] is traffic conditioning that takes place after egress decapsulation. An important exception is that the configuration of a tunnel (e.g., the absence of traffic conditioning at tunnel ingress) and/or the diffserv domains involved may require that all traffic exiting a tunnel pass through diffserv traffic conditioning to fulfill the diffserv edge node traffic conditioning responsibilities of the tunnel egress node. Tunnel designers are strongly encouraged to include the ability to require that all traffic exiting a tunnel pass through diffserv traffic conditioning in order to ensure that traffic exiting the node is compatible with the egress node's diffserv domain.
[5-外部]和[6-之后]的交通调节在逻辑上与隧道分开，因为它不受隧道脱封的影响。隧道设计和规范应允许在这些位置进行区分服务流量调节。此类调节可被视为独立于隧道，即，[5-外部]是在隧道出口之前进行的交通调节，[6-之后]是在出口脱封之后进行的交通调节。一个重要的例外是，隧道的配置（例如，隧道入口没有流量调节）和/或所涉及的区分服务域可能要求所有离开隧道的流量通过区分服务流量调节，以履行隧道出口节点的区分服务边缘节点流量调节职责。强烈鼓励隧道设计者能够要求所有离开隧道的流量通过diffserv流量调节，以确保离开节点的流量与出口节点的diffserv域兼容。
In contrast, the [4 - Inner] location is difficult to employ for traffic conditioning because it requires reaching inside the packet to operate on the inner IP header. Unlike the [3 - Inner] case for encapsulation, there is no need for functionality to be performed at [4- Inner], as diffserv traffic conditioning can be appended to the tunnel decapsulation (i.e., performed at [6 - After]).
相反，[4-内部]位置很难用于流量调节，因为它需要到达数据包内部才能在内部IP报头上操作。与封装的[3-内部]情况不同，不需要在[4-内部]执行功能，因为diffserv流量调节可以附加到隧道去封装（即，在[6-之后]执行）。
The elimination of parallel functionality and data paths from decapsulation causes a potential loss of information. As shown in the above diagram, decapsulation combines and reduces two DSCP values to one DSCP value, losing information in the most general case, even if arbitrary functionality is allowed. Beyond this, allowing arbitrary functionality poses a structural problem, namely that the DSCP value from the outer IP header would have to be presented as an out-of-band input to the traffic conditioning block at [6 - After], complicating the traffic conditioning model.
从解除封装中消除并行功能和数据路径会导致潜在的信息丢失。如上图所示，解除封装将两个DSCP值合并并减少为一个DSCP值，在最常见的情况下，即使允许使用任意功能，也会丢失信息。除此之外，允许任意功能还带来了一个结构性问题，即来自外部IP报头的DSCP值必须在[6-之后]作为带外输入呈现给流量调节块，从而使流量调节模型复杂化。
To avoid such complications, the simpler approach of statically selecting either the inner or outer DSCP value at decapsulation is recommended, leaving the full generality of traffic conditioning functionality to be implemented at [5 - Outer] and/or [6 - After]. Tunnels should support static selection of one or the other DSCP value at tunnel egress. The rationale for this approach is usually only one of the two DSCP values contains useful information. The conceptual model for the tunnel provides a strong indication of which one contains useful information; the outer DSCP value usually contains the useful information for tunnels based on the uniform model, and the inner DSCP value usually contains the useful information for tunnels based on the pipe model. IPSec tunnels are usually based on the pipe model, and for security reasons are currently required to select the inner DSCP value; they should not be configured to select the outer DSCP value in the absence of an adequate security analysis of the resulting risks and implications.
为避免此类复杂情况，建议采用更简单的方法，在去封装时静态选择内部或外部DSCP值，使交通调节功能的全部通用性在[5-外部]和/或[6-之后]实现。隧道应支持在隧道出口处静态选择一个或另一个DSCP值。这种方法的基本原理通常是两个DSCP值中只有一个包含有用信息。隧道的概念模型提供了一个强有力的指示，其中一个包含有用的信息；外部DSCP值通常包含基于统一模型的隧道的有用信息，内部DSCP值通常包含基于管道模型的隧道的有用信息。IPSec隧道通常基于管道模型，出于安全原因，当前需要选择内部DSCP值；在没有对产生的风险和影响进行充分的安全分析的情况下，不应将其配置为选择外部DSCP值。
As a sanity check on the egress DSCP selection approach proposed above, this subsection considers a situation in which a more complex approach might be required. Statically choosing a single DSCP value may not work well when both DSCPs are carrying information that is relevant to traffic conditioning.
作为对上述出口DSCP选择方法的健全性检查，本小节考虑了可能需要更复杂方法的情况。当两个DSCP都携带与流量调节相关的信息时，静态选择单个DSCP值可能无法正常工作。
As an example, consider a situation in which different AF groups [RFC 2597] are used by the two domains at the tunnel endpoints, and there is an intermediate domain along the tunnel using RFC 791 IP precedences that is transited by setting the DSCP to zero. This situation is shown in the following IP header flow diagram where I is the tunnel ingress node, E is the tunnel egress node and the vertical lines are domain boundaries. The node at the left-hand vertical line sets the DSCP in the outer header to 0 in order to obtain compatibility with the middle domain:
作为一个例子，考虑在隧道端点中两个域使用不同的AF组[RFC 2597 ]的情况，并且在隧道中使用通过将DSCP设置为零来转换的RFC 791 IP优先级的中间域。这种情况如以下IP报头流程图所示，其中I是隧道入口节点，E是隧道出口节点，垂直线是域边界。左侧垂直线处的节点将外部标头中的DSCP设置为0，以获得与中间域的兼容性：
| |
+-----|-------------------|------+
/ | | \
>>-----------I-------|-------------------|--------E---------->>
| |
Ingress DS Domain RFC 791 Egress DS domain
IP Precedence
Domain
| |
+-----|-------------------|------+
/ | | \
>>-----------I-------|-------------------|--------E---------->>
| |
Ingress DS Domain RFC 791 Egress DS domain
IP Precedence
Domain
In this situation, the DS edge node for the egress domain (i.e., the node at the right-hand vertical line) can select the appropriate AF group (e.g., via an MF classifier), but cannot reconstruct the drop precedence information that was removed from the outer header when it
在这种情况下，出口域的DS边缘节点（即，右侧垂直线处的节点）可以选择适当的AF组（例如，通过MF分类器），但不能重构在其被删除时从外部报头移除的丢弃优先级信息
transited the RFC 791 domain (although it can construct new information via metering and marking). The original drop precedence information is preserved in the inner IP header's DSCP, and could be combined at the tunnel egress with the AF class selection communicated via the outer IP header's DSCP. The marginal benefit of being able to reuse the original drop precedence information as opposed to constructing new drop precedence markings does not justify the additional complexity introduced into tunnel egress traffic conditioners by making both DSCP values available to traffic conditioning at [6 - After].
传输RFC 791域（尽管它可以通过计量和标记构建新信息）。原始的丢弃优先级信息保留在内部IP报头的DSCP中，并且可以在隧道出口处与经由外部IP报头的DSCP通信的AF类选择相结合。与构建新的下降优先标记相比，能够重用原始下降优先信息的边际效益并不能通过在[6-之后]使两个DSCP值可用于交通调节来证明引入隧道出口交通调节器的额外复杂性。
A related issue involves protocol translators, including those employing the Stateless IP/ICMP Translation Algorithm [RFC 2765]. These translators are not tunnels because they do not add or remove a second IP header to/from packets (e.g., in contrast to IPv6 over IPv4 tunnels [RFC 1933]) and hence do not raise concerns of information propagation between inner and outer IP headers. The primary interaction between translators and diffserv is that the translation boundary is likely to also be a diffserv domain boundary (e.g., the IPv4 and IPv6 domains may have different policies for traffic conditioning and DSCP usage), and hence such translators should allow the insertion of diffserv edge node processing (including traffic conditioning) both before and after the translation processing.
一个相关的问题涉及协议转换器，包括那些采用无状态IP/ICMP转换算法[RFC2765]的协议转换器。这些转换器不是隧道，因为它们不会向数据包添加或从数据包中删除第二个IP头（例如，与IPv4隧道上的IPv6相比[RFC 1933]），因此不会引起内部和外部IP头之间的信息传播问题。转换器和diffserv之间的主要交互是转换边界可能也是diffserv域边界（例如，IPv4和IPv6域可能具有不同的流量调节和DSCP使用策略），因此此类转换器应允许插入diffserv边缘节点处理（包括交通调节）翻译处理前后。
The security considerations for the diffserv architecture discussed in [RFC 2474, RFC 2475] apply when tunnels are present. One of the requirements is that a tunnel egress node in the interior of a diffserv domain is the DS ingress node for traffic exiting the tunnel, and is responsible for performing appropriate traffic conditioning. The primary security implication is that the traffic conditioning is responsible for dealing with theft- and denial-of-service threats posed to the diffserv domain by traffic exiting from the tunnel. The IPSec architecture [RFC 2401] places a further restriction on tunnel egress processing; the outer header is to be discarded unless the properties of the traffic conditioning to be applied are known and have been adequately analyzed for security vulnerabilities. This includes both the [5 - Outer] and [6 - After] traffic conditioning blocks on the tunnel egress node, if present, and may involve traffic conditioning performed by an upstream DS-edge node that is the DS domain ingress node for the encapsulated tunneled traffic.
[RFC 2474，RFC 2475]中讨论的diffserv体系结构的安全注意事项适用于存在隧道的情况。其中一个要求是，diffserv域内部的隧道出口节点是用于离开隧道的流量的DS入口节点，并负责执行适当的流量调节。主要的安全含义是，流量调节负责处理从隧道中退出的流量对diffserv域造成的盗窃和拒绝服务威胁。IPSec架构[RFC 2401]对隧道出口处理施加了进一步的限制；除非已知要应用的流量调节的属性，并且已经对安全漏洞进行了充分分析，否则将丢弃外部报头。这包括隧道出口节点上的[5-外部]和[6-之后]流量调节块（如果存在），并且可能涉及由上游DS边缘节点执行的流量调节，上游DS边缘节点是用于封装隧道流量的DS域入口节点。
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC 791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC 1661]辛普森，W.“点对点协议（PPP）”，STD 51，RFC 1661，1994年7月。
[RFC 1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC 1933]Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 1933，1996年4月。
[RFC 2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC 2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC 2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC 2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC 2474] 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, December 1998.
[RFC 2474]Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC 2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC 2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597. June 1999.
[RFC 2597]Heinanen，J.，Baker，F.，Weiss，W.和J.Wroclawski，“保证货运PHB集团”，RFC 2597。1999年6月。
[RFC 2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999.
[RFC 2598]Jacobson，V.，Nichols，K.和K.Poduri，“快速转发PHB”，RFC 2598，1999年6月。
[RFC 2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter. "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[RFC 2661]西部汤斯利、A.巴伦西亚、A.鲁本斯、G.帕尔、G.佐恩和B.帕尔特。“第二层隧道协议”L2TP“，RFC 26611999年8月。
[RFC 2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC 2765]Nordmark，E.“无状态IP/ICMP转换算法（SIIT）”，RFC 2765，2000年2月。
Some of this material is based on discussions with Brian Carpenter, and in particular his presentation on this topic to the diffserv WG during the summer 1999 IETF meeting in Oslo. Credit is also due to a number of people working on tunnel specifications who have discovered limitations of the diffserv architecture [RFC 2475] in the area of tunnels. Their patience with the time it has taken to address this set of issues is greatly appreciated. Finally, this material has benefited from discussions within the diffserv WG, both in meetings and on the mailing list -- the contributions of participants in those discussions are gratefully acknowledged.
其中一些材料基于与Brian Carpenter的讨论，特别是他在1999年夏季奥斯陆IETF会议期间向diffserv工作组提交的关于该主题的演讲。这也归功于许多致力于隧道规范的人员，他们发现了diffserv架构[RFC 2475]在隧道领域的局限性。我们非常感谢他们对解决这一系列问题所花时间的耐心。最后，本材料得益于diffserv工作组在会议上和邮件列表上的讨论——感谢与会者在这些讨论中的贡献。
David L. Black EMC Corporation 42 South St. Hopkinton, MA 01748
David L.Black EMC公司马萨诸塞州霍普金顿南大街42号01748
Phone: +1 (508) 435-1000 x75140
EMail: black_david@emc.com
Phone: +1 (508) 435-1000 x75140
EMail: black_david@emc.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。