本备忘录为Internet团体提供了相关信息，但并未规定任何类型的标准。本备忘录的发
布不受任何限制。
版权声明

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

摘要
本文考虑了使用不同形式IP隧道的区分服务（diffserv）（RFC2474,RFC2475）之间的
交互作用。有关区分服务中隧道的讨论(RFC2475)并没有给隧道的设计和实现者提供充分的
指导。本文描述了使用IP隧道的区分服务交互作用的两个概念模型，并且利用它们研究了
功能的结果配置和组合。在当前隧道封装和解封过程中，如何以及在何处执行区分服务流量
调节是一个值得考虑的问题。目前，已经提出了一些简单的机制用来限制由于采用隧道而为
区分服务流量调节模型增加的复杂性。在某些环境下，IPSec隧道的安全性考虑会限制一些
可能的功能。

目录
1．本文的约定 2
2.区分服务与隧道概述 2
3．区分服务隧道的概念模型 3
3.1 全DS能力配置的概念模型 4
3.2 部分DS能力配置的考虑 4
4．入口功能 5
4.1 入口DSCP选择和重组 6
4.2 隧道选择 7
5．出口功能 7
5.1 出口DSCP选择 8
5.2 出口DSCP选择情况研究 9
6．区分服务和协议转换器 9
7．安全考虑 10
8．参考 10
9．鸣谢 11
10．作者地址 11
11．版权信息 11
12．致谢 12

1．本文的约定
IP隧道通过隧道的IP包封装在另一个IP头中。存在两种IP头是IP隧道定义的特征，
但在这两个头之间还可能会有附加头。内IP头是原始包；外IP头在隧道端点添加和解除。
通常，隧道间的网络中间节点只对外部IP头进行操作，并且有区分服务功能的中间节点只
访问或修改外部IP头的DSCP域。“隧道”和“IP”隧道在本文中是等价的。简单的说，本
文中的隧道即是指IP隧道（i.e.，对于那些没有封装的IP头的而言），当然也还存在其它类
型的隧道，如MPLS（多协议标签交换）路径和由第二层（链路层）头封装而成的“隧道”，
虽然这里描述的概念模型和手段有助于理解区分服务与这类隧道的交互。
本文分析认为隧道是单向的；双向隧道可看作是由具有相同端点、传输方向相反的两个
单向隧道组成。一个隧道由入口、出口和一些中间节点组成。在隧道入口，通信进入隧道并
通过增加外IP头来进行封装；在隧道出口，通信离开隧道并删除外IP头进行解包；隧道通
信通过入口和出口则要经过一些中间节点。本文没有假设隧道通信的路由和转发，非凡是是
否存在任何形式的routepinning。
2.区分服务与隧道概述
在复杂性方面，隧道覆盖了从简单的IP-in-IP隧道一直到更复杂的多协议隧道，比如
IPSec传输方式中的IPinPPPinL2TP。最常见的隧道配置并不是端到端的。例如，隧道通
信时的入口节点和出口节点并非是信源端和信宿端。这种隧道可以实施多源和目标的通信。
假如入口节点是隧道中所有通信的端到端源节点或者出口节点是端到端目标节点，则结果配
置就可得到简化，其中可应用本文中大部分的分析和指导。
一个主要值得考虑的问题是区分服务码点字段（DSCP）在IP头[RFC2474,RFC2475]
中的应用。区分服务的体系结构答应中间节点检查并修改DSCP的值，这将会导致外部IP
头中DSCP的值在隧道入口和出口之间已经被修改。假如一个隧道不是端到端的，就有可能
需要在入口将它包含的DSCP及一些其它信息告诉外部IP头并在出口处返还给内部IP头。
当前隧道实现者面对的一个问题就是[RFC2475]并未提供完备的指导。例如，一些PHB规范
按照第三节的G.7显式规定了可以在外部IP头中使用来进行隧道通信的PHB。这点造成了
很大的限制：举个例子，假如一个规范需要在内部IP头和外部IP头中均使用同样的PHB，
按照该规定的流量就无法在不支持PHB的域或网络间以隧道方式传输。
这里应该使用更灵活些的手段来描述那些在进行隧道通信时需要保存的重要PHB行为
属性，并且答应以任何能充分保存属性的方式对外部IP头进行标记。
本文提出了一种方法，其中流量调节可以同隧道入口和出口处理串行进行，而不是并行
进行。这种方法并没有创建任何通过隧道端点传递信息的附加的通路，所有的区分服务信息
被包含在IP头的DSCP字段中。IPSec体系结构[RFC2401]需要这种方法在IPSec隧道出口
处保存安全属性，但是这种手段也通过引入带外输入避免了复杂的区分服务流量调节块。采
用这种手段的结果是使[RFC2475]第三节G.7的最后一句话变得毫无意义，因为还没有一种
隧道出口区分服务构件既能同时使用内DSCP和外DSCP。
这种流量调节手段的附带好处是考虑到流量调节和隧道封装/解封装构件，它并没有对
服务域边界定位加以任何附加限制。一个有趣的配置分类包括一个通过网络节点的区分服务
域边界；这样的边界能够在进行隧道封装与解封的域间拆分创建一个类DMZ的区域。对于这
种类DMZ区域区分服务流量调节并不适合，因为流量调节是区分服务域的操作和治理。
3．区分服务隧道的概念模型
这里基于全区分服务网络的假设提出了两个IP隧道流量调节的概念性模型。这一配置
并不适用于3.2节。
3.1 全DS能力配置的概念模型
第一个概念模型是个通用模型,它从流量调节观点把IP隧道看作是一个端到端路径的人
工设施；隧道对于将通信流量送到信宿端是必需的，但对流量调节方面没有重要的影响。在
这种模型中，每个包都有一个DS字段用于在任何一点进行流量调节，即最外层IP头的DS
字段；任何其他的均被忽略。这种模型的实现是在封装的时候把DSCP的值拷贝到外部IP
头，并且在解封装的时候把外部头的DSCP的值拷贝到内部IP的头。因为区分服务流量调
节功能并不受IP隧道存在的影响，使用这种模型，配置IP隧道可不必考虑区分服务域边界。
第二种概念模型是一种管道模型，它把IP隧道视为将节点隐藏于入口和出口之间，并
不参与流量调节。在该模型中，隧道出口节点必须使用隧道入口通过内部IP头的DSCP字
段传入的流量调节信息，并且忽略外部头的DSCP值。管道模型并不能完全隐藏隧道内的流
量调节，因为在隧道中间节点丢弃和规整的影响可能在隧道出口和外部可见。
假如入口和出口节点在不同的区分服务域，管道模型拥有流量调节结果。在这种情况下，
出口节点必须进行流量调节来确保隧道中的流量的DSCP值对于区分服务域出口是可接受
的（参见第六节的区分服务结构）。可以用在区分服务域的入口和出口节点间的内部域TCA
（通信调节协议）减少和消除出口流量调节。要完全消除出口流量调节就需要在入口和出口
的区分服务域对流量采用兼容的服务提供策略，并且以一致的形式支持所有的PHB组和
DSCP值。某些虚拟专用网络隧道就提供了类似的例子。尽管可能会被网络中间节点物理地
分开，但是通过使隧道端点虚拟比邻，可以将这些隧道视为把不同的区分服务域在其端点处
连接到一个区分服务区。
这种管道模型也适用于DSCP本身携带信息通过隧道的情况。举例来说，假如通过一条
使用EFPHB的路径进行域间传输，AFPHBDSCP值中的丢弃优先权信息会丢失，除非采取
一些措施来保护它。IP隧道就是一种可能的保护机制。假如由于同这些域兼容的DSCP码点
限制集的原因而没有使用隧道，则在DS端点间要通过一个和多个非区分服务域的路径就会
经历类似的信息丢失现象。
3.2 部分DS能力配置的考虑
假如只有隧道的出口节点有DS能力，则[RFC2475]要求当区分服务域为域外流量提供
隧道通信时，出口节点能进行任何边界流量调节。假如出口节点不是一个DS边缘节点，满
足这种需求的办法就是在一个适当的DS上游边缘节点进行流量调节，并且在隧道解包处理
时把外部IP头中的DSCP字段拷贝到内部IP头；这样就在出口节点的区分服务域内把通用
模型应用到了部分隧道。另一个办法是在解封处理的时候丢弃外DSCP值，减少随之发生的
流量调节问题和对那些普通DS入口节点的需求。这样就在出口节点的区分服务域内把管道
模型应用到了部分隧道，因此用于DSCP标记的相邻上游节点是隧道的入口节点，而不是紧
邻的上游中间节点。
假如只有隧道的入口节点有DS能力，则[RFC2475]要求隧道的流量合并与隧道出口网
络相兼容。假如隧道解封处理时丢弃了外IP头的DSCP值而没有改变内IP头的DSCP值，DS
隧道的入口节点有责任把内IP头DSCP值设为与隧道出口网络相兼容的值。为了实现这一目
的，许多现存的隧道工具都使用值0（DSCP=000000。假如出口网络像[RFC791]中那样实
现IP优先级，那么可能会用到[RFC2474]中定义的部分或全部的八位DSCP码点选择器。DSCP
码点不同于分类器，并不是普遍适应于这种目的，因为正确的操作经常要求在DS不可用的
隧道出口节点提供区分服务功能。
4．入口功能
如第三节所述，本文所基于的方法中，区分服务功能和/或带外通信路径与隧道封装过
程不是并行的。这样就有三个可能的位置来进行隧道封装过程相关的流量调节，下图描述了
IP头通过隧道封装的流程：
+---------[2-Outer]-->>
/
/
>>----[1-Before]--------Encapsulate------[3-Inner]-->>
由于流量调节不受隧道封装的影响，在[1-Before]处的流量调节就在逻辑上与隧道分
开，因此隧道设计和规范应该答应其存在。在[2-Outer]处的流量调节会和隧道协议进行
交互，因此轻易受到包重组的影响。像在5.1节中深入讨论的那样，这样的隧道可能需要限
制在[2-Outer]的功能。尽管[2-Outer]的流量调节可能要负责标注流量使之与要进入的
下一个区分服务域兼容，但假如没有重组敏感性，就没必要施加任何限制。
比较起来，因为需要直接访问包内部对对内IP头进行操作，在[3-Inner]的位置很难
用于流量调节。对于IPSec隧道以及任何其它经过加密或采用密码完整性检查的隧道而言这
是不可能的。因此在[3-Inner]的流量调节经常只被作为隧道封装过程的一部分进行，使
得封装和隧道调节的实现复杂化。在许多情况下，可以通过在其它两个位置的流量调节组合
来实现期望的功能，这两个位置均能够独立于隧道封装指定和实现。
一个异常情况是，当非DS隧道出口在解包的过程中丢弃了外部IP头时，在[3-Inner]
就必须进行流量调节，并且内部IP头中的DSCP必须与出口网络相兼容。大部分情况下在封
装的过程中把内部DSCP字段设为0,分类器的DCSP码点也很有作用，因为他们对支持IP
优先的网络[RFC971]有效。
下面的表格总结了前（B），外部（O），内部（I）的DSCP值和相应的流量调节逻辑位置
间的可完成关系。

关系通信调节位置
--------------------------------------------
B=I=O不需要通信调节
B!=I=O[1-Before]
B=I!=O[2-Outter]
B=O!=I作为封装的一部分有限制地支持:
I可以被设为000000或可能的一个分类选择器码点值
B!=I!=O以上三种的某种组合。

表中后两行所示的一个[1-Before]和[2-Outter]的组合可适用于许多情况，并且
可以更好地配置[3－Innner]的功能。即使DSCP的值没有变化，为了进行速率和突发控制
仍然需要进行流量调节。
4.1 入口DSCP选择和重组
假如IP隧道对包重组敏感，则必须或应该限制使用它的DS的行为集合。假如包属于允
许重组的行为集合，则区分服务体系结构也应答应对包进行重组；例如被不同分类选择器标
记的行为集合。IPSec[RFC2401]和L2TP[RFC2661]提供了一个对包重组敏感的隧道的例子。
假如IPSec配置了反回放支持，那么对超过一定水平的包重组都将产生一个审计事件，指示
出潜在的安全问题。可以配置L2TP来在出口节点恢复入口的顺序，不仅消除了任何建立在
隧道重排基础上的区别，也会消极地影响通信（例如：通过增加延迟）。通用模型不能完全
的应用于这种隧道，简单地将不同的行为集合混合在一起会导致一些不可预知的交互。
最简单地能够避免使用重组敏感隧道协议进行重组而导致非预期交互的方法就是不使
用这样的协议或特征，但是这往往是不可能的。当使用这样的协议或特征时，可以通过确保
通过隧道的聚集流在[2-Outter]处被标记来组成一个单序集合来避免交互（例如，PHB
共享一个能阻止包重组的排序约束）。隧道协议规范应该说明一个隧道是否和在什么环境下
应该限制为一个单序集合以及何时不受限制。
为了上面提到的IPSec和L2TP，当配置了有重族敏感的协议特征时，规范应该限制每个
隧道为一个单序集合，并且会采取措施限制所有隧道来避免在协议特征改变或隧道流量组合
时产生不希望的结果。区分服务的实现不应该企图期望这些隧道本身来为封装微流提供基于
重组的区分。假如这些隧道需要基于重组的区分，则相同端点间应该使用多并行隧道。这使
不同隧道的包重组和个别不支持包重组的隧道可以共存。对于IPSec和相关的安全协议，因
为任何使用多隧道的流量分析也能通过建立在外IP头的DSCP使用单隧道流量来实现，所以使
用单隧道来实现多排序集合比使用多隧道没有加密的优势。一般来说，支持多隧道还需要一
些附加资源（例如，加密环境），并且在决定是否使用它们时应该考虑多隧道对于网络治理
的影响。
4.2 隧道选择
在决定对什么流量使用隧道时，隧道的行为特性要重点考虑的。其中包括所有参与域的
服务提供策略，不仅仅是在隧道[2-Outter]标记的PHB和DSCP。举个例子，假如EF是利用
隧道的唯一流量，且隧道提供的方式能充分保护EFPHB特性，那么即使以默认的PHB隧道传
送EFPHB通信不是个好主意，至少也是可以接受的。
服务提供策略要负责防止像通过一个不完备的默认隧道转发EF造成的的不匹配。当一个
有多行为特征的多并行隧道可用时，服务提供策略要负责决定哪个数据流使用哪个隧道。在
所有的可能性当中，有一个通用隧道模型的简单版本，它使用内部DSCP的值来选择一个隧道，
并用与通信的PHB相兼容的行为集合来转发通信。
5．出口功能
如上面第三节中所述，本分析是建立的基础是，区分服务功能和/或带外的通信线路与
隧道封装的过程是非并行的。这就答应3个可能的位置来进行关于隧道解封的流量调节。如
下图所示，描述了IP头在隧道解封过程中的流程：
>>----[5-Outer]-------------+


>>----[4-Inner]---------Decapsulate----[6-After]-->>
在[5-Outter]和[6-After]的流量调节在逻辑上同隧道分离，因为它并不受隧道解封
的影响。隧道设计和规范应该答应在这些位置的区分服务流量调节。这些调节可被看作是独
立于隧道的，[5–Outer]是发生在隧道出口前的流量调节，[6-After]是发生在出口解封后
的流量调节。一个重要的例外是，隧道配置（例如，在入口处没有流量调节）和区分服务域
可能要求所有离开隧道的流量通过区分服务的流量调节来完成隧道出口节点的区分服务边
节点流量调节责任。为了确保流量离开节点时与出口节点的区分服务域兼容，鼓励隧道设计
者提供功能使所有的流量都通过区分服务的流量调节来离开隧道。
比较起来，在[4-Inner]的位置很难进行流量调节，因为它需要到包内部对内IP头进行
操作。不像封装过程中的[3-Inner]，没有必要在[4-Inner]执行功能，因为区分服务流量
调节可以附加到隧道解封的过程中，如在[6–After]处执行。
5.1 出口DSCP选择
并行功能的消除和解封装数据路径造成了潜在的信息丢失的可能，如上图所示，解封装
把两个DSCP值减少为一个，丢失了信息，即使答应任意功能。除此之外，答应任意功能也
会造成结构性问题，即外部IP头的DSCP值必须作为带外输入提交给[6-After]的流量
调节块，这使流量调节模型趋于复杂。
为了避免这样的复杂化，一个简单的办法就是在解封时静态地选择内部或外部DSCP值，
把全部的流量调节留给[5-Outter]和/或[6-After]来实现。隧道应该支持在隧道
出口静态选择一个或其它DSCP值。这种方法的基本原理就是两个DSCP值中只有一个包含了
有用信息。该隧道的概念模型强烈的暗示了哪个DSCP包含了有用信息；在通用模型中，外
部DSCP值经常包含隧道的有用信息，而在管道模型中，内部DSCP值经常包含了隧道的有用
信息。IPSec隧道经常基于管道模型，并且由于安全原因，一般需要选择内部DSCP值；它
们不应该在没有对结果风险和意义进行足够安全分析的情况下配置为选择外部DSCP值。
5.2 出口DSCP选择情况研究
如上面所讲的在出口处对DSCP选择方法的完整检查，本小节考虑的情况需要更复杂的
手段。当DSCP字段都携带了与流量调节相关的信息时，就不可能静态地选择一个单DSCP
值。
例如，考虑这样一种情况，隧道端点的两个域使用不同的AF组[RFC2597]，并且有
隧道的一个中间域使用RFC791IP优先权，它要将设置DSCP为0来传输。如下面的IP头
流程图所示。在图中，I是隧道入口节点，E是隧道出口节点，垂直线是域边界。为了与中
间域的兼容性，竖线左边的节点将外部头中的DSCP设置为0。

+------------------------------+
/
>>-----------I----------------------------------E---------->>

入口DS域RFC791出口DS域
IP优先域
在这种情况下，出口域的DS边缘节点可以选择适当的AF组（例如：通过一个MF分类
器），但不能重建在RFC791域传送时从外部头删除的丢弃优先信息。（尽管他可以通过测算
或标记来重建新的信息）。原始的丢弃优先信息被保存在内IP头的DSCP字段，并且可以在
隧道出口处与通过外部IP头的DSCP传输的AF类型选择进行组合。能够重用原始丢弃优先
信息相对于建立新的丢弃优先信息的附带好处在于，使两个DSCP值对于[6-After]的流量
调节可用而不用调整引入到隧道出口流量调节中的附加复杂性。
6．区分服务和协议转换器
一个相关的问题是协议转换器，包括那些采用无状态IP/ICMP转换算法。这些转换器
不是隧道，因为它们没有在包上增/删二级IP头。（例如：IPv6overIPv4隧道[RFC1933]）
因此没有引起在内外IP头间的信息传播。转换器与区分服务最主要的交互是转换边界类似
于区分服务域边界（例如：IPv4和IPv6可能有不同的通信调节策略和DSCP用法），并且因
此这种转换器应该答应将区分服务边缘节点处理（包括通信调节）插入到转换处理的前后。
7．安全考虑
当隧道存在时，可应用[RFC2474][RFC2475]中讨论的区分服务体系结构安全考虑。一
个要求是区分服务域内的一个隧道出口节点是通信退出隧道的DS入口节点，并且要负责进
行适当的流量调节。主要的安全意义在于流量调节要对流量离开隧道造成区分服务域偷窃
和拒绝服务负责。IPSec结构[RFC2401]隧道出口处理上有更多的限制；除非流量调节的
属性是已知的并且为了安全而经过了充分分析，外部头才能丢弃。其中包括可能存在于隧道
出口节点的[5-Outter]和[6–After]的流量调节块和上游DS节点（且是封装隧
道流量的DS域入口节点）的流量调节。
8．参考
[RFC791]Postel,J.,"InternetProtocol",STD5,RFC791,September
1981.
[RFC1661]Simpson,W.,"ThePoint-to-PointProtocol(PPP)",STD51,
RFC1661,July1994.
[RFC1933]Gilligan,R.andE.Nordmark,"TransitionMechanismsfor
IPv6HostsandRouters",RFC1933,April1996.
[RFC2003]Perkins,C.,"IPEncapsulationwithinIP",RFC2003,
October1996.
[RFC2401]Kent,S.andR.Atkinson,"SecurityArchitectureforthe
InternetProtocol",RFC2401,November1998.
[RFC2474]Nichols,K.,Blake,S.,Baker,F.andD.Black,
"DefinitionoftheDifferentiatedServicesField(DS
Field)intheIPv4andIPv6Headers",RFC2474,December
1998.
[RFC2475]Blake,S.,Black,D.,Carlson,M.,Davies,E.,Wang,Z.
andW.Weiss,"AnArchitectureforDifferentiated
Services",RFC2475,December1998.
[RFC2597]Heinanen,J.,Baker,F.,Weiss,W.andJ.Wroclawski,
"AssuredForwardingPHBGroup",RFC2597.June1999.
[RFC2598]Jacobson,V.,Nichols,K.andK.Poduri,"AnEXPedited
ForwardingPHB",RFC2598,June1999.
[RFC2661]Townsley,W.,Valencia,A.,Rubens,A.,Pall,G.,Zorn,G.
andB.Palter."LayerTwoTunnelingProtocol"L2TP"",RFC
2661,August1999.
[RFC2765]Nordmark,E.,"StatelessIP/ICMPTranslationAlgorithm
(SIIT)",RFC2765,February2000.
9．鸣谢
本文的某些部分是建立于BrianCarpenter的讨论基础之上，非凡是他1999夏天在Oslo
的IETF会议上有关这方面的区分服务WG讲演。同时要感谢那些为撰写隧道规范而工作的
人们，他们发现了区分服务体系结构结构在隧道应用方面的局限。感谢他们为本文付出的耐
心。最后，本文得益于区分服务WG通过会议和邮件列表进行的内部讨论。对所有参与讨
论的人致以崇高的谢意。
10．作者地址
DavidL.Black
EMCCorporation
42SouthSt.
Hopkinton,MA01748
Phone:+1(508)435-1000x75140
EMail:black_david@emc.com
11．版权信息
Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsUChcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
12．致谢
FundingfortheRFCEditorfunctioniscurrentlyprovidedbytheInternetSociety.