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.




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隧道的安全注意事项在某些情况下限制了可能的功能。

1. Conventions used in this document
1. 本文件中使用的公约

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


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.


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.


2. Diffserv and Tunnels Overview
2. 区分服务和隧道概述

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.


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.


3. Conceptual Models for Diffserv Tunnels
3. 区分服务隧道的概念模型

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.


3.1 Conceptual Models for Fully DS-capable Configurations
3.1 完全支持DS配置的概念模型

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


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.


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.


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域的路径可能会遇到类似的信息丢失现象。

3.2 Considerations for Partially DS-capable Configurations
3.2 部分支持DS配置的注意事项

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功能。

4. Ingress Functionality
4. 入口功能

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:


                                        +--------- [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.


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.


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.


   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.


4.1 Ingress DSCP Selection and Reordering
4.1 入口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


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.


4.2 Tunnel Selection
4.2 隧道选择

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.


5. Egress Functionality
5. 出口功能

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 conditioners with respect to tunnel decapsulation processing, as shown in the following diagram that depicts the flow of IP headers through tunnel decapsulation:


   >>----[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.


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]).


5.1 Egress DSCP Selection
5.1 出口DSCP选择

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.


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.


5.2 Egress DSCP Selection Case Study
5.2 出口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.


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,以获得与中间域的兼容性:

                        |                   |
                 /      |                   |       \
                        |                   |
      Ingress DS Domain        RFC 791         Egress DS domain
                            IP Precedence
                        |                   |
                 /      |                   |       \
                        |                   |
      Ingress DS Domain        RFC 791         Egress DS domain
                            IP Precedence

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


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值可用于交通调节来证明引入隧道出口交通调节器的额外复杂性。

6. Diffserv and Protocol Translators
6. 区分服务和协议转换器

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边缘节点处理(包括交通调节)翻译处理前后。

7. Security Considerations
7. 安全考虑

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域入口节点。

8. References
8. 工具书类

[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月。

9. Acknowledgments
9. 致谢

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工作组在会议上和邮件列表上的讨论——感谢与会者在这些讨论中的贡献。

10. Author's Address
10. 作者地址

David L. Black EMC Corporation 42 South St. Hopkinton, MA 01748

David L.Black EMC公司马萨诸塞州霍普金顿南大街42号01748

   Phone: +1 (508) 435-1000 x75140
   Phone: +1 (508) 435-1000 x75140
11. Full Copyright Statement
11. 完整版权声明

Copyright (C) The Internet Society (2000). All Rights Reserved.


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.






Funding for the RFC Editor function is currently provided by the Internet Society.