區分服務和隧道

本備忘錄為Inte.net團體提供了相關信息，但并未規定任何類型的標準。本備忘錄的發
布不受任何限制。
版權聲明

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域?！八淼馈焙汀癐P”隧道在本文中是等價的。簡單的說，本
文中的隧道即是指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配置了反回放支持，那么對超過一定水平的包重組都將產生一個審計事件，指示
出潛在的安全問題?？梢耘渲肔2TP來在出口節點恢復入口的順序，不僅消除了任何建立在
隧道重排基礎上的區別，也會消極地影響通信（例如：通過增加延遲）。通用模型不能完全
的應用于這種隧道，簡單地將不同的行為集合混合在一起會導致一些不可預知的交互。
最簡單地能夠避免使用重組敏感隧道協議進行重組而導致非預期交互的方法就是不使
用這樣的協議或特征，但是這往往是不可能的。當使用這樣的協議或特征時，可以通過確保
通過隧道的聚集流在[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
revokedbytheInternetSocietyoritssuclearcase/" target="_blank" >ccessorsorassigns.

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