本文檔的狀態
本文檔為互連網社區提供一般性的知識。并未定義任何互連網標準。對本文檔資料的
分發、傳播不受限制。

版權聲明
Copyright(C)TheInternetSociety(1998).AllRightsReserved.

摘要
本文檔定義了一種可以在互連網上實現可擴展的分類業務的體系結構。這種體系結構
通過標記ip層數據包的DS段[DSFIELD]，體現不同的業務級別，從而提供擴展性業務。
在一個數據包的傳輸路徑上的每一節點，都根據該數據包的分類標記為其提供特定的傳輸
服務。復雜的分類，標記，傳輸策略，及整形操作僅僅需要在網絡邊緣或用戶主機上實
現。網絡資源根據服務策略而被分配給不同的業務流。這些服務策略治理著業務數據在進
入一個具有分類業務能力的網絡時，如何標記，調整，并在網絡中向前傳輸。在這些基本
分類業務模塊的基礎上，可以實現各種各樣的服務。




目錄

1 介紹 3
1.1 綜述 3
1.2 術語 4
1.3 需求 6
1.4 和其它方法的比較 7
2 分類業務體系結構模型 8
2.1 分類業務域（DS域） 8
2.1.1 DS邊界節點和內部節點 9
2.1.2 DS入口節點和出口節點 9
2.2 分類業務區域 9
2.3 業務量分類和調節 9
2.3.1 分類器 10
2.3.2 業務量簡檔 10
2.3.3 業務量調節器 10
2.3.4 業務量調節器和MF分類器的位置 12
2.4 每一跳行為 13
2.5 網絡資源分配 13
3 每一跳行為（PHB）的規范設計指導方針 14
4 與非分類業務兼容節點的互操作 16
5 關于組播 17
6 安全和隧道問題 17
6.1 竊取和拒絕服務 17
6.2 IPSEC和隧道交互 18
6.3 審查 19
7 感謝 20
8 參考文獻 20
9 作者聯系地址 21
10 完整版權聲明 22





1 介紹
1.1 綜述
本文檔定義了一種可以在互聯網上提供可擴展的分類業務的體系結構。一種“業務”，是
由在一個網絡內，在同一個傳輸方向上，通過一條或幾條路徑傳輸數據包時的某些重要特征所
定義的。這些特征可能由吞吐率，時延，時延抖動，和/或丟包率的量化值或統計值所指定，
也可能由其獲取網絡資源的相對優先權來指定。業務分類要求能適應不同應用程序和用戶的需
求，并且答應對互聯網服務的分類收費。
本體系結構由許多在網絡節點上實現的功能實體組成，包括每一跳轉發行為集合，數據包
分類功能，和業務量調節功能。其中，業務量調節功能又有測量，標記，整形，和監察四部
分。在本體系結構，只在網絡的邊界節點上實現復雜的分類和調節功能。并且，通過在IPv4
和IPv6包頭的DS段做適當的標記[DSFIELD]，把業務量歸為集合，然后根據所做的標記，
采取不同的每一跳轉發策略。因此，本體系結構具備可擴展性。“每一跳行為”保證了在每個
網絡節點，為互相競爭資源的業務流分配緩沖區和帶寬資源時，有一個合理的處理粒度。在核
心網絡節點上，為每個應用程序業務流或者為每個用戶維護一個轉發狀態是不可行的。在以下
功能中是有區別的：
? 向業務集合提供的服務
? 用于實現某種服務的調節功能和每一跳行為
? 用于標記數據包從而選擇每一跳行為的DS段值（DS編碼點）
? 實現每一跳行為時，特定節點的實現機制
在網絡內部節點，服務提供和業務量調節策略被有效地同數據包轉發策略分離開。這樣，
保證了網絡可以提供相當廣泛的服務類型，并給未來的擴展留下足夠的空間。
本體系結構只在一個業務流方向上提供分類業務，它是非對稱的。開發出一種對稱式的體
系結構是目前研究的一個課題，但已經超出了本文檔的描述范圍；感愛好的讀者可以參考
[EXPLICIT]。
1.2節是本文檔使用的術語表。1.3節列出了本體系結構所解決的需求。1.4節提供了與其
它分類業務解決方案的簡要比較。第2節具體介紹了本體系結構中的各個模塊。第3節建議了
每一跳行為規范的設計準則。第4節討論了與沒有實現本文檔及[DSFIELD]定義的分類業務
功能的節點和網絡的互操作問題。第5節討論了與多點傳送有關的問題。第6節討論安全和隧
道問題。

1.2 術語
本節給出了在本文檔中所使用術語的一般性概念解釋。其中的某些術語將在文檔后面章節
中給出更準確的解釋。

行為集合（BehaviorAggregate:BA） 一個DS行為集合。
BA分類器（BAClassifier） 僅基于DS段的內容選擇數據包的分類器。
邊界連接（BoundaryLink） 連接兩個域的邊界節點的連接。
分類器（Classifier） 根據已定義的規則和包頭內容選擇數據包的
實體。
DS行為集合（DSBehaviorAggregate） 在一個特定方向上，通過一條連路傳輸的具
有相同DS編碼點的數據包集合。
DS邊界節點（DSBoundaryNode） 在DS域中，負責連接另一個ＤＳ域或者連接
一個沒有ＤＳ功能的域的節點。
具有ＤＳ功能（DS-capable） 實現了本體系結構中定義的分類業務功能
的；通常用于形容一個由ＤＳ兼容節點組成
的域。
ＤＳ編碼點（DSCodepoint） ＤＳ段中ＤＳＣＰ部分的特定值，用于選擇
ＰＨＢ。
ＤＳ兼容（DS-compliant） 能夠支持在[DSFIELD]，本文檔，和其它有
關分類業務的文檔中定義的分類業務功能
的；通常用來形容一個節點或者網絡設備。
ＤＳ域（DSDomain） 具有ＤＳ功能的域；連續分布的節點的集
合，它們具有共同的服務提供策略和ＰＨＢ
定義。
ＤＳ出口節點（DSEgressNode） 處理離開此ＤＳ域的業務流的ＤＳ邊界節
點。
ＤＳ入口節點（DSIngressNode） 處理進入此ＤＳ域的業務流的ＤＳ邊界節
點。
ＤＳ內部節點（DSInteriorNode） 非邊界節點的ＤＳ節點。
ＤＳ段（DSField） 在ＩＰｖ４中，指ＴＯＳ字節；在ＩＰｖ６
中，指業務類型字節。其中的ＤＳＣＰ段諸
比特用于編碼ＤＳ編碼點，其它的比特目前
沒有使用。
ＤＳ節點（DSNode） ＤＳ兼容的節點
ＤＳ區（DSRegion） 連續分布的ＤＳ域的集合，在其上可以建立
跨越多個ＤＳ域提供分類業務的連路。
下游ＤＳ域（DownstreamDSDomain） 一個邊界連接中，位于業務流下游的ＤＳ
域。
丟包器（Dropper） 負責丟包的功能模塊。
丟包（Dropping） 基于一定的原則丟棄數據包；參見監察
（Policing）。
遺留節點（LegacyNode） 實現了在[RFC791，RFC1812]中定義的
IPv4優先算法，但并非DS兼容的節點。
標記器（Marker） 負責標記的功能模塊。
標記（Marking） 基于一定的原則設置一個數據包的DS編碼
點；參見預標記（PRe-marking），重標記
（Re-marking）。
機制（Mechanism） 在節點中用于實現一種或多種每一跳行為的
非凡算法或操作（例如，排隊策略）。
測量器（Meter） 負責測量的功能模塊。
測量（Metering） 計算由分類器選中的業務流的時間性特征
（例如，速率）。這一過程的即時狀態可能
會影響標記器，整形器，或者丟包器的行
為，也可能被用于記帳收費或者純粹的測量
目的。
微流（Microflow） 一個獨立的從應用程序到應用程序的數據包
流，由源地址，源端口號，目的地址，目的
端口號和協議標識符區分。
MF分類器（MFClassifier） 根據任意數目的包頭字段的內容來選擇數據
包的多字段（MF）分類器。典型的字段組合
可能包括源地址，目的地址，DS段，協議標
識符，源端口號和目的端口號。
每一跳行為（Per-Hop-Behavior:PHB） 在DS兼容節點上，作用在DS行為集合上的
外界可觀察的轉發行為。
PHB組（PHBGroup） 由一個或多個PHB組成的集合。這些PHB
由于共同的限制，例如隊列服務或隊列治理
策略，必須同時被指定及實現。PHB組提供
了構建服務的基石，使得一系列的轉發行為
可以被同時指定。一個單獨的PHB是PHB
組的特例。
監察（Policing） 根據依照某種業務量簡檔工作的測量器的狀
態，丟棄（通過丟包器）業務流的部分數據
包。
預標記（Pre-mark） 在數據包進入下游DS域之前，設置其DS編
碼點。
提供者DS域（ProviderDSDomain） 具有DS功能的服務提供者所屬的源域。
重標記（Re-mark） 改變數據包的DS編碼點。通常由標記器根據
TCA確定如何修改。
服務（Service） 在DS域內或者在端到端條件下，對用戶業務
量的一個確定的子集所采取的所有處理措
施。
服務水平協議（ServiceLevelAgreement：SLA） 用戶和服務提供者之間達成的關于如
何為用戶提供轉發服務的服務協議。這里的
用戶可能是一個使用者組織（源域），也可
能是另一個ＤＳ域（上游域）。服務水平協
議SLA可以包括部分或全部組成一個ＴＣＡ
的業務量調節規則。
服務提供策略（ServiceProvisioningPolicy） 關于業務調節器如何配置到ＤＳ邊界節點
上，及業務流如何映射到特定的ＤＳ行為集
合以獲得某些服務的策略。
整形器（Shaper） 負責業務量整形的功能模塊。
整形（Shaping） 有意延遲業務流中的某些數據包，以使業務
流符合預先定義的業務量簡檔。
源域（SourceDomain） 發出接受某種特定服務的業務流的節點所在
的域。
業務量調節器（TrafficConditioner） 負責完成業務量調節功能的功能實體。包括
測量器，標記器，丟包器，和整形器。業務
量調節器可以重新標記業務流，或者丟棄或
整形數據包，從而改變業務流的時間特征，
使業務流符合事先達成的業務量簡檔。
業務量調節（TrafficConditioning） 實現ＴＣＡ中確定的控制規則，包括測量，
標記，整形，和監察。
業務量調節協議（TrafficConditioningAgreement:TCA） 一份指明應用到分類器選中
的業務流的分類規則，相應的業務量簡檔，
以及對此業務流的測量，標記，丟棄，和／
或整形規則的協議。ＴＣＡ包括來自三方面
的業務量調節規則：ＳＬＡ顯式指定，相關
的服務需求隱式指定，和／或來自于ＤＳ域
的服務提供策略。
業務量簡檔（TrafficProfile） 關于業務流的時間特征的描述，例如速率和
突發包大小。
業務流（TrafficStream） 具有治理重要性的通過同一段路徑的一個或
多個微流的集合。業務流可能包含由特定的
分類器選出的活動的微流集合。
上游ＤＳ域（UpstreamDSDomain） 一個邊界連接中，位于業務流上游的ＤＳ
域。

1.3 需求
在互聯網的發展歷史上，從主機數目，到應用程序的種類和數量，再到網絡基礎設施的能
力，都有著持續的增長。而且，這種增長在可預見的未來還會持續。因此，必須有一種支持分
類業務的可擴展體系結構與這種持續增長相適應。
在這種體系結構中，下列需求必須得到認可，并能被滿足：
? 提供從端到端或者在特定網絡（或網絡集合）內部的，多種多樣的服務和提供策略。
? 答應將服務從特定的應用程序中分離出來。
? 能夠與已有的應用程序共存，而無須改變應用程序編程接口或者主機軟件（假設適當
配置了分類器，標記器，和其它的業務量調節功能模塊）。
? 應該在核心網絡節點實現時，將業務量調節和服務提供功能同轉發行為相分離。
? 不應依靠逐跳的應用程序信令。
? 僅需要一個很小的轉發行為集合。其實現復雜性不應是網絡設備開銷的主要部分，也
不應給未來高速系統的實現引入瓶頸。
? 應該避免在核心網絡節點內為每個微流或者每個用戶保持各自的狀態。
? 在核心網絡節點內，應僅保存集合分類狀態。
? 答應在核心網絡節點實現簡單的數據包分類（BA分類器）。
? 答應同無DS兼容性的網絡節點的合理的互操作性。
? 具備增量式布署能力。

1.4 和其它方法的比較
在本文檔中定義的分類業務體系結構可以同其它已存在的分類業務模型相比較。我們把這
些可選的模型分為如下幾類：相對優先級標記，服務標記，標簽交換，集成業務/RSVP，和靜
態逐跳分類。
相對優先級標記模型的例子包括[RFC791]定義的IPv4優先級標記，802.5令牌環優先級
[TR]，和缺省的802.1p業務量分類[802.1p]。在這個模型中，應用程序，主機，或者代理節
點為數據包選擇一個相對優先級（例如，延遲或者丟棄優先級）。在整個傳輸路徑上的網絡節
點根據包頭中指定的優先級采取相應的轉發行為。我們的體系結構可以被認為是這種模型的更
新。在這種體系結構中，更清楚的指明了邊界節點和業務量調節器的作用及重要性；并且，每
一跳行為模型也答應比相對延遲或丟棄優先級更具一般性的轉發行為。
服務標記模型的一個例子是[RFC1349]定義的IPv4TOS。在這個例子中，每個數據包被
標記為需求某種“服務類型”，包括“延遲最小化”，“吞吐量最大化”，“可靠性最大
化”，或者“費用最小化“。網絡節點根據標記的服務類型選擇路由或者轉發行為。這個模型
同我們的體系結構有細微的差別。請注重，我們并沒有描述使用DS段做為路由選擇的輸入。
[RFC1349]定義的TOS標記具有廣泛的一般性，無法擴展可能的服務語義范圍。而且，其服
務需求是與每一個數據包相關聯的，但有些服務語義可能依靠于一系列數據包的整體轉發行
為。服務標記模型不能很輕易的適應未來服務范圍和數量的增長（鑒于其編碼空間太小），而
且在每一個核心網絡節點都會涉及“TOS到轉發行為”的轉換。服務標記的標準化還意味著提
供服務的標準化，這已經超出了IETF的工作范圍。注重服務提供記錄在分配的DS編碼空間
中，從而答應具有本地重要性的編碼點被提供者用于提供服務標記語義[DSFIELD]。
標簽交換（或叫做虛電路）模型的例子包括幀中繼，ATM，和MPLS[FRELAY，ATM]。
在這種模型中，沿網絡路徑的每一跳，都建立業務流的路徑轉發狀態和業務治理或QoS狀態。
各種不同粒度的業務量集合在入口節點處與一條標簽交換路徑相關聯。在每一標簽交換路徑
內，數據包或信元被賦予一個轉發標簽。轉發標簽負責尋找下一跳節點，每一跳轉發行為，和
在每一跳時的標簽置換。由于標簽并非全局性的，而只是在一條鏈路上有效，所以這種模型允
許對業務量分配資源時能采取更好的粒度。也正因為如此，網絡資源可以被預留給在某條鏈路
上收到的具有特定標簽的數據包或信元集合，同時，標簽交換語義控制著下一跳路由選擇，允
許業務流通過非凡設計的路徑穿過網絡。這種改進的粒度控制是以增加建立和維護標簽交換路
徑的治理和配置需求為代價的。并且，在最好情況下，每個節點保存的轉發狀態數量與邊界節
點數量成正比（假設存在多點到點的標簽交換路徑）；在最壞情況下（采用提供資源的邊到邊
標簽交換路徑），與邊界節點數量的平方成正比。
集成業務/RSVP模型在缺省情況下依靠傳統方式轉發數據包，同時，它也答應發送方和接
收方通過信令交互在兩者之間的路徑上每個節點處建立額外的數據包分類和轉發狀態
[RFC1633，RSVP]。由于缺少對業務流的歸類，每個節點保存的狀態數將與并發的資源預留
數成正比。在一些高速鏈路上，這個數目可能會很大。這個模型還需要應用程序支持資源預留
信令協議。在核心網絡節點，可以使用分類業務機制將集成業務/RSVP狀態歸類[BERNET]。
集成業務/RSVP模型的一個變種通過在網絡路徑沿途的每個節點處只采用“靜態”分類和
轉發策略，使逐跳進行信令交互變的不再需要。這些策略是治理級的，并非針對網絡中的活動
微流。這個變種的狀態需求可能會比RSVP更多，非凡是在骨干網節點處。因為隨著時間推
移，一個節點所采用的靜態策略數可能比在此節點請求資源預留的活動的發送-接收對話數還要
多。雖然采用大數量的分類規則和轉發策略在計算復雜性上可行，但由此而需要在業務流必經
的骨干網節點處安裝和維護這些規則的治理負擔也是需要認真考慮的。
以上把我們提出的體系結構與其它的分類業務模型進行了比較。需要注重的是，采用這些
技術的鏈路和節點應該是通過基于第二層交換的網絡結構（例如，802.1p局域網，幀中繼
/ATM骨干網）互連DS節點，來提供分類業務行為和語義。對于MPLS（多協議標簽交換）
條件下，可以作為可選的域內實現技術。在DS域（或者在提供DS域接入的網絡內）的特定
區域采用非凡的鏈路層技術，意味著對業務流更粗粒度的分類。依靠于從PHB到不同的鏈路
層服務的映射和把數據包安排到有限優先級（或者不同類型和能力的虛電路）的方式，全部或
部分使用中的PHB是可被支持的（或者是不可辨別的）。

2 分類業務體系結構模型
分類業務體系結構基于這樣一個簡單模型：進入網絡的業務量在網絡邊緣處進行分類和可
能的調節，然后被分配到不同的行為集合中去。每一個行為集合由唯一的DS編碼點標識。在
網絡核心處，數據包根據DS編碼點對應的每一跳行為轉發。在本節中，我們討論在分類業務
區域中的要害組件，業務量分類和調節功能，以及分類業務是如何通過業務量調節和基于PHB
的轉發而實現的。

2.1 分類業務域（DS域）
DS域是鄰接的DS節點集合。這些DS節點執行共同的服務提供策略，并實現相同的
PHB組。每個DS域都擁有完好定義的邊界。位于邊界處的DS邊界節點負責將進入此DS域
的業務流分類及進行可能的調節，以保證穿過此DS域的數據包被適當標記，并按照DS域所
支持的PHB組中的一個PHB轉發。DS域內的節點根據DS編碼點為數據包選擇轉發行為。
從DS編碼點值到某個被支持的PHB組的映射，依靠的是推薦的編碼點到PHB的映射規則或
者用戶定義的本地化映射規則[DSFIELD]。假如在DS域中包含非DS兼容節點，那么很可能
導致性能表現的無法猜測，并且會妨礙服務水平協議（SLA）的實現。
一個DS域通常包含一個或多個處于同一組織治理下的網絡；例如，一個組織的內部網或
者一個Internet服務提供商（ISP）。域治理者必須保證有足夠的資源被提供和/或預留，從
而足以支持域提供的SLA。
2.1.1 DS邊界節點和內部節點
DS域由DS邊界節點和DS內部節點組成。DS邊界節點連接本DS域和其它DS域或者
無DS能力的域，DS內部節點連接同一DS域的其它DS內部節點或者邊界節點。
無論是DS邊界節點還是內部節點都必須能夠按照DS編碼點信息采用合適的PHB轉發數
據包；否則會導致有不可猜測的行為發生。另外，DS邊界節點可能還需要實現其所在DS域
和其連接的對等DS域之間的業務量調節協議（TCA）所定義的業務量調節功能（參見2.3.3
節）。
內部節點可能會實現有限的業務量調節功能，例如DS編碼點的重新標記。那些實現了更
為復雜的分類和業務量調節功能的內部節點與DS邊界節點類似（參見2.3.4.4節）。
一臺DS域網絡中的主機對于源于其上運行的應用程序的業務流，相當于一個DS邊界節
點；因此我們稱這臺主機在DS域內。假如這臺主機并未實現邊界節點功能，那么在拓撲結構
上最靠近此主機的DS節點，將為主機業務流提供DS邊界節點功能。

2.1.2 DS入口節點和出口節點
DS邊界節點對于不同方向的業務流，既可以是DS入口節點，又可以是DS出口節點。業
務流在DS入口節點處進入DS域，在DS出口節點處離開DS域。DS入口節點負責保證進入
DS域的業務流符合本域和此節點直連的另一個域之間的TCA。DS出口節點依據兩個域之間
的TCA細節，對轉發到其直連的對等域的業務流執行業務量調節功能。注重DS邊界節點在某
些接口中可以作為DS內部節點。

2.2 分類業務區域
一個或多個鄰接的DS域統稱為分類業務區域（DS區）。DS區可以支持貫穿區內多個
DS域的分類業務。
DS區中的DS域可能支持不同的PHB組，和編碼點到PHB的映射規則。不過，為了提
供貫穿多個DS域的業務，每個對等的DS域都必須建立定義（無論顯式的或是隱式的）了
TCA的對等SLA。TCA指明了如何在域邊界處調節從一個DS域傳向另一個DS域的業務
流。
DS區內的DS域也可以采用相同的服務提供策略，并支持相同的PHB組和編碼點映射。
這樣的好處是消除了在DS域間進行業務量調節的需求。

2.3 業務量分類和調節
分類業務通過在上游網絡和下游DS域之間建立服務水平協議（SLA）跨越DS域邊界。
SLA指定了數據包分類和重標記規則，也指定了業務量簡檔和對于符合或不符此簡檔的業務流
采取的處理方法（參見2.3.2節）。域間的TCA就是從SLA以直接或間接的方式取得的。
數據包分類策略負責識別出業務量子集，這個子集通過被調節和/或映射到一個或多個行為
集合（通過DS編碼點重標記）而取得分類服務。
業務量調節包括測量，整形，監察和/或重標記。其目的是為保證進入DS域的業務流符合
TCA指定的規則。業務量調節的外延依靠于具體的服務細節，涵蓋的范圍從簡單的編碼點重標
記到復雜的業務監察和整形操作。業務量調節策略的細節應該由網絡間協商確定，這個問題不
在本文檔論述范圍內。

2.3.1 分類器
數據包分類器根據數據包包頭的某些字段內容選取業務流中的數據包。我們定義了兩種分
類器。行為集合分類器（BA分類器）僅根據DS編碼點對數據包分類。多字段分類器（MF分
類器）根據包頭中的一個或多個字段值，例如源地址，目的地址，DS段，協議標識符，源端
口號，目的端口號，以及其它信息如引入接口，對數據包分類。
分類器的任務就是選出匹配某種規則的數據包，然后指導它們進入其它的業務量調節器模
塊接受進一步處理。分類器必須由某個治理例程根據合適的TCA進行配置。
分類器還必須鑒別它用來分類數據包的信息的有效性。（參見第6節）
注重，在上游數據包分片的情況下，MF分類器在檢察傳輸層包頭時，可能將來自同一數
據包的后續分片錯誤分類。這個問題的一種可能的解決方案是保存分片狀態信息；然而，由于
上游分片可能亂序到達，也可能采取不同的路由，導致這種解決方案缺少一般性。解決數據包
分片問題的策略不在本文檔論述范圍內。

2.3.2 業務量簡檔
業務量簡檔描述了分類器選出的業務流的時間特征。它提供了判定一個特定的數據包是否
符合業務量簡檔的規則。例如，一份基于令牌桶的簡檔可能會如此描述：
codepoint=X,usetoken-bUCketr,b
上面的簡檔說明，所有DS編碼點值為X的數據包應該通過速率為r，桶大小為b的令牌
桶測量器的檢測。在本例中，不符合簡檔的數據包是那些當它們到達時，桶中剩下的令牌已不
足的。符合及不符簡檔這樣的兩級標準可以擴展到多級。就是說，可以定義多個級別的簡檔一
致性，而不僅是符合，不符合這樣兩種情況。
對于符合簡檔和不符合簡檔的數據包可以采取不同的調節行為，或者不同計費方法。符合
簡檔的數據包無須進一步的調節便可進入DS域；或者，可選的，可以改變它們的DS編碼
點。后一種情況發生在DS編碼點第一次被設為非缺省值時[DSFIELD]，或者發生在數據包進
入一個對此業務流使用不同的PHB組或編碼點到PHB映射策略的DS域時。不符合簡檔的數
據包被放入隊列，直到它們符合簡檔（整形），被丟棄（監察），標記一個新編碼點（重標
記），或者直接轉發但需采用另外的計費標準。不符合簡檔的數據包可能被映射到一個或多個
更低優先級的行為集合。這里的更低優先級是指在轉發性能的某些方面，低于同類數據包中符
合簡檔的那些所屬的行為集合（BA）。
注重，業務量簡檔是TCA的可選組件，其使用依靠于服務提供和域服務提供策略的具體說
明。

2.3.3 業務量調節器
業務量調節器包括下列組件：測量器，標記器，整形器，和丟包器。業務流首先經過分類
器的選擇，然后被分類器送往業務量調節器的某個組件處。測量器負責（在適當處）測量業務
流是否符合業務量簡檔。測量器對一個特定數據包的測量結果（例如，是否符合簡檔）會影響
對此數據包的標記，丟棄，或整形行為。
當數據包在DS邊界節點處離開業務量調節器時，每個數據包的DS編碼點都會被賦予一
個適當值。
圖1說明了分類器和業務量調節器的模塊結構。注重，業務量調節器并不一定需要所有四
個組件。例如，在沒有有效的業務量簡檔時，數據包可能只通過分類器和標記器。


圖1：數據包分類器和業務量調節器邏輯框圖

2.3.3.1 測量器
業務量測量器負責測量由分類器根據TCA指定的業務量簡檔選出的數據包流的時間特征。
測量器將其測量結果（也稱為測量器狀態）傳遞給其它調節功能模塊，從而引發對符合或不符
（在某種程度上）業務量簡檔的每個數據包的非凡處理。

2.3.3.2 標記器
數據包標記器負責把數據包的DS段設置為特定的編碼點值，并將標記過的數據包加入到
特定的DS行為集合中去。標記器可能被配置為把所有送給它的數據包標記為唯一的編碼點
值，也可能被配置為根據測量器狀態把數據包標記為一些編碼點值中的一個值。假如標記器改
變了數據包的編碼點，那么我們就說標記器“重標記”了此數據包。

2.3.3.3 整形器
整形器負責延遲一個業務流中部分或全部數據包的傳輸，以便使業務流符合業務量簡檔的
要求。整形器通常有一個有限大小的緩沖區，當緩沖區沒有更多的空間容納需延遲的數據包
時，數據包就會被丟棄。

2.3.3.4 丟包器
丟包器負責丟棄一個業務流中部分或全部的數據包，以便使業務流符合業務量簡檔的要
求。這一過程也被稱做“監察”業務流。注重，丟包器可以作為一個非凡的整形器（該整形器
緩沖區大小為零或僅能容納幾個數據包）而實現。

2.3.4 業務量調節器和MF分類器的位置
業務量調節器通常位于DS入口和出口邊界節點處，但也可能位于DS域，或非DS域的
內部節點處。

2.3.4.1 在源域內
我們定義源域為發起接受非凡服務的業務流的節點所在的DS域。位于源域中的業務源和
媒介節點可以實現業務量分類和調節功能。從源域中發出并穿越邊界的業務流可能直接被業務
源做上標記，或者在離開源域之前由媒介節點標記。這兩種方式分別被稱為“初始標記”和
“預標記”。
考慮這樣一個例子：在一家公司中，CEO的數據包通常要求有較高優先級。CEO的主機
會把所有其發出的數據包的DS編碼點標記為一個代表“較高優先級”的值。或者，由CEO
主機直接連接的第一跳路由器負責把CEO的數據包分類，并做適當的標記。象這樣的高優先
級業務流也可能在靠近數據源處進行調節，以便對特定數據源發出的高優先級業務的總量有所
限制。
在業務源處對數據包進行標記有幾點優勢。首先，業務源更輕易獲得應用程序的需求。因
此，它在確定哪些數據包應該享受更好的轉發待遇時，可以將應用程序的需求納入考慮。另
外，在業務流與來自其它數據源的業務流合并之前對其數據包分類，要更簡單。因為此時一個
節點所使用的分類規則的數量會較少。
鑒于數據包的標記可能分散在多個節點處進行，源DS域有責任保證流向其服務提供者DS
域的業務流集合與適當的TCA相符合。額外的分配機制，如帶寬代理或RSVP，可能被用來為
提供者網絡中特定的DS行為集合動態分配資源[3BIT，Bernet]。源域的邊界節點應該保證業
務流符合TCA，必要時，要對數據包監察，整形，或重標記。

2.3.4.2 在DS域邊界
業務流可能在邊界連接的任何一端（上游域DS出口節點或者下游域DS入口節點）被分
類，標記或者調節。域間的SLA應指明由哪個域負責將業務流映射到DS行為集合，以及調節
這些集合使之符合適當的TCA。然而，DS入口節點必須假定流入的業務流不符合TCA，因此
必須預備根據本地策略強制執行TCA。
假如數據包在上游域中被預標記和調節，那將意味著下游域只需支持很少的分類和業務量
調節規則。在這種情況下，下游DS域可能只需要根據TCA對流入的行為集合重標記或監察。
然而，那些具有路徑依靠或源依靠性的更復雜業務可能還需要下游DS域入口節點進行MF分
類。
假如DS入口節點與一個無DS功能的上游域連接，那么DS入口節點就必須能對流入的
業務執行所有需要的業務調節功能。

2.3.4.3 在無DS功能的域內
在無DS功能的域內的業務源或媒介節點可以使用業務量調節器在業務流到達下游DS域
入口節點之前預標記之。這樣，本地分類和標記策略將被隱藏。

2.3.4.4 在內部DS節點處
盡管基本體系結構假設復雜的分類和業務量調節功能位于網絡的入口和出口邊界節點處，
在網絡內部節點處配置這些功能也并未被排除。例如，在一條越洋鏈路上，需要有更多更嚴格
的接入策略，這就需要在這條鏈路的上游節點處實現MF分類和業務量調節功能。當然，這種
方法在可擴展性上有些限制。因為那將意味著在一個節點上，維護大量的分類和調節規則。

2.4 每一跳行為
每一跳行為（PHB）是指DS節點運用于特定DS行為集合上的，外部可觀察的轉發行
為。“轉發行為”在這里是一個廣義概念。例如，當僅有一個行為集合占用一條鏈路時，可觀
察的轉發行為（如，丟包率，延遲，時延抖動）就只依靠于鏈路的相對負載（即是說，在“行
為”采用一種工作保存式的調度策略）。有意義的行為上的差別通常產生于在同一個節點，多
個行為集合競爭緩沖區和帶寬資源的情況下。PHB是節點給行為集合分配資源的一種方法，正
是基于這種逐跳進行資源分配的機制，我們才構筑了分類業務模型。
PHB的最簡單例子是保證至少把一條鏈路帶寬的X%（在一定的時間間隔內）分配給一個
行為集合。這種PHB在各種業務競爭條件下都可以被公正并且很輕易的測量。另一種稍復雜
點的PHB要求確保最少占有X%的鏈路帶寬，同時享受相應份額的鏈路剩余帶寬。一般來說，
PHB的可觀察行為依靠于對相關行為集合或其它行為集合的業務量特性的約束。
PHB通過指定其相對于其它PHB的資源（如，緩沖區，帶寬）優先級來定義，也可能通
過它們的可觀察業務量特性（如，延遲，丟包率）來定義。這些PHB可以作為資源分配的基
石，并且一致性起見，應被指定為一組（PHB組）。PHB組中的每一PHB都享有共同的限
制，例如數據包安排或者緩沖區治理策略等。同組的PHB間的聯系在于它們絕對的或者相對
的優先級（例如，采用確定閾值或隨機閾值的丟包優先級），但是這并不是必須的（例如，N
等分鏈路資源）。一個單獨定義的PHB可以看作是PHB組的特例。
在節點處，PHB是通過一定的緩沖區治理和數據包安排策略實現的。PHB是通過與服務
提供策略相聯系的行為特征定義的，而不是根據采取了何種實現機制。一般來說，可以有很多
種實現機制去實現特定的PHB組。而且，在一個節點上，可以實現多于一個的PHB組，并在
域內使用。所定義的PHB組應該保證適當的組間資源分配簡單易行，并且能夠實現同時支持
兩組或更多組的集成機制。一個PHB組定義時，應指明其與已有組之間可能的沖突。這些沖
突可能來自于有些操作不答應同時執行。
如[DSFIELD]中描述，在節點處，根據收到數據包的DS編碼點選擇PHB。標準化的
PHB有推薦的編碼點。然而，全部編碼點空間遠大于分配給標準化PHB使用的編碼點空間，
[DSFIELD]把剩余空間提供給了局部使用。編碼點到PHB的映射表可以即包括一對一，也包
括N對一的映射。注重，所有的編碼點都必須被映射到某一PHB：在缺少某些局部策略的情
況下，那些沒有映射到標準化PHB的編碼點應該被統一映射到一個缺省PHB。

2.5 網絡資源分配
在DS域節點上實現，配置，操作和治理的PHB組，應能根據域服務提供策略，有效的分
配使用這些節點的資源，以及節點間鏈路。業務量調節器可以通過執行TCA，或者從域中節點
或其它業務量調節器取得反饋，從而更有效的控制資源的使用。盡管在沒有復雜的業務量調節
功能時，也可以提供很多服務（例如，僅使用靜態標記策略），但類似于監察，整形，和動態
重標記這樣的功能，可以答應向用戶提供具有量化的性能參數的服務。
業務量調節器及內部節點間的配置和交互需要有域高層的治理控制，可能還需要一個控制
實體和適當的協議。控制模型的實現方案有很多種。
這些模塊之間交互的準確特征和實現細節超出了本體系結構的范圍。然而，可擴展性要求
域的控制不需要網絡資源的微治理。最具擴展性的控制模型應在開環方式下在操作時隙內操作
節點，并且由于SLA是變化的，所以只需要治理時間刻度內的治理操作。這種簡單模型可能在
某些情況下并不適用，此時，一些自動的但緩慢改變的操作控制（按分鐘而不是秒）在平衡對
網絡資源的適用方面就會更具吸引力。

3 每一跳行為（PHB）的規范設計指導方針
對每一跳行為進行標準化的基本要求在[DSFIELD]中給出。本節具體闡述PHB（組）定
義時的其它要求。主要目的是幫助建立PHB實現時的一致性。當一個PHB組標準化時，它必
須滿足這些要求，從而保持本體系結構的完整性。
G.1：一個標準PHB必須從為標準映射保留的編碼區域內[DSFIELD]，選擇一個推薦的
DS編碼點。推薦的編碼點由IANA指定。一個PHB提議可以從EXP/LU空間內選取一個臨
時編碼點，以便進行域間實驗。注重，不能要求檢查包頭除DS域以外的信息域來確定該數據
包所對應的PHB。
G.2：每一個新提出的PHB組規范應該包括其行為及行為目的的概述。概述中應包括此
PHB組要解決的問題的描述。還應包括此PHB組涉及的基本概念。這些概念應包括，但不僅
限于，隊列行為，丟棄行為，和輸出鏈路選擇行為。最后，概述中應闡明此PHB組解決所描
述問題的方法。
G.3：PHB組規范應說明其包括的單個PHB的個數。當PHB組包括多于一個PHB時，
PHB組規范就必須對這些PHB間的交互和限制做出具體說明。例如，規范必須說明假如同一
微流中不同的數據包被標記為此組中不同的PHB時，數據包被重新排序的可能性是否會增
大。
G.4：假如PHB組的特定功能依靠于某些外部限制，比如服務提供限制，那么PHB定義
中，就必須說明當這些限制被違反時，此PHB所產生的行為。更進一步，假如這些限制被違
反時，又需要采取類似包丟棄或重標記的行為，那么這些行為應被非凡規定。
G.5：一個PHB組可能被指明為僅在一個域內局部使用。其作用是在域內提供面向特定
域的功能或服務。在這種情況下，PHB規范有助于向服務提供者提供一份關于此PHB組的一
致性定義。然而，任何只定義為局部使用的PHB組，不能進行標準化。但是，它們可以作為
知識性RFC文檔發表。相反的，作為通用的PHB組，就必須經過嚴格的標準化過程。所以，
所有的PHB組提議都必須明確指明其用途是通用的還是局部的。
PHB組可能被設計來提供主機到主機，WAN邊界到WAN邊界，和/或域邊界到域邊界服
務。出于一致性考慮，在PHB定義中使用“端到端（hosttohost）”應被理解為“主機到
主機”。
由于實驗或操作要求，在域內還可以定義和配置其它PHB組。這些局部有效的PHB組并
不需要公開定義，但是它們應使用EXP/LU空間的編碼點（[DSFIELD]中定義）。
G.6：被標記為PHB組中某個PHB的數據包，有可能在域中或域邊界處，重標記為同
PHB組中的另一個PHB。有三種典型情況需要這種轉換：
a. 與此PHB組對應的編碼點，也被用來攜帶網絡狀態信息。
b. 需要提升或降低數據包的PHB的情況。（假如組內的PHB可進行某種排序）
c. 域邊界處缺少SLA。這種情況下，數據包通過邊界鏈路時的編碼點/PHB根據上游域
的局部策略決定。
PHB規范應該清楚的說明數據包被重標記（例如，提升或降低）為本組中另一個PHB的
情況。假如某些情況下不能改變數據包的PHB，那么規范中必須清楚說明此時改變PHB的后
果。改變數據包的PHB（無論改為同組的，還是不同組），可能引起的后果之一是，對微流中
數據包重新排序的可能性增加。PHB可能攜帶某些主機到主機，WAN邊界到WAN邊界，和
/或域邊界到域邊界的語義，這些語義很難在數據包重標記為組內（或其它組）另一個PHB時
保存下來。
對于某些PHB組，可以通過重標記數據包為組內其它PHB來反映節點狀態的變化。假如
一個PHB組被設計來反映網絡狀態，那么在相應的PHB規范中，就必須詳述組中各個PHB
與其反映的網絡狀態之間的聯系。此外，假如這些PHB對節點轉發行為有所限制，那么這些
限制可以被表達為節點應當，或必須執行的行為。
G.7：PHB組規范中應包括一節說明隧道技術在本組的應用。此節應說明當數據包被封裝
入隧道后，如何根據其內層包頭的DS域，來確定外層包頭DS域。還應說明，在隧道出口
處，內層包頭應做如何的改變。（參見6.2節）。
G.8：定義PHB組是一個增量式的過程。當定義新的PHB組時，應說明它如何與已定義
的PHB組協調。每一個新建立的PHB組，其作用的范圍可能是全新的，也可能是已有PHB
組的擴展。假如一個PHB組完全獨立于某些或全部已有PHB組規范，那么在其規范中應有一
節詳述它如何與已經標準化的PHB組共存。例如，這一節中應該說明當微流中的數據包被標
記為與兩個不同PHB組都相關的編碼點時，它們被重排序的可能性有多大。假如在同一節點
中同時操作兩個（或更多）PHB組不可能或是有害的，這種情況必須在此節中說明。假如節點
在處理同時收到的被標記為兩個（或更多）PHB組的多個數據包時，需采取某些非凡動作，那
么這些非凡動作也應在此節說明。
定義PHB組時，應注重避免循環定義。
假如提議中的PHB組是已有的某個PHB組的擴展，那么規范中應包括一節詳述此PHB
組如何與被擴展PHB組交互。更進一步，假如此PHB組改變或更狹義的定義了某些已有行
為，這些情況也應在規范中說明。
G.9：每個PHB規范都應包括一節闡述實現此PHB組的最小一致性需求。這一節主要目
的是提供此PHB組實現時容許變化的行為的變動范圍。這一節可以采用規則，表格，偽代
碼，或測試的形式敘述。
G.10：PHB規范應包括一節詳述其行為的安全性。此節應包括對在隧道出口改變內層包
頭的編碼點，以及這種改變對數據包轉發行為的影響的討論。
另外，此節還應討論提議的PHB組如何被用在拒絕服務攻擊，減少服務協議攻擊，和違
反服務協議攻擊。最后，此節應討論檢測這些攻擊的可能方案。
G.11：PHB規范中應包括一節詳述配置和治理問題。這些問題可能影響PHB的操作和使
用此PHB的候選服務。
G.12：強烈建議每個PHB規范都提供一個附錄，詳述其對現有服務和潛在服務提供的服
務行為特征。這些服務包括但不限于用戶特定的，設備特定的，域特定的或端到端的服務。強
烈建議附錄中包括一節描述用戶，設備，和/或域如何驗證這些服務。
G.13：建議每個PHB規范提供一個附錄。此附錄面向域內部使用，提供本域向不支持此
PHB組的對等域轉發數據包時選擇何種PHB的指導。
G.14：建議每個PHB規范提供附錄說明提議的PHB組對已有的高層協議的影響。在某
些情況下，PHB答應對高層協議做可能的改變，這些改變可能增加，也可能減少提議的PHB
組的使用。
G.15：建議每個PHB規范提供附錄，對使用共享媒體或交換的鏈路層提供從PHB到鏈
路層QoS機制映射的建議。在PHB和鏈路層QoS機制之間進行適當的映射涉及許多因素，
這個問題已超出本文檔的論述范圍；然而，在PHB規范中應設法給出一些指導。

4 與非分類業務兼容節點的互操作
我們把非分類業務兼容節點（non-DS-compliantnode）定義為任何不會根據
[DSFIELD]描述譯解DS域，和/或沒有實現部分或全部標準化PHB組（或只在特定DS域使
用的PHB組）的節點。這可能域節點的能力或配置有關。我們把遺留節點（legacynode）定
義為非分類業務兼容節點的非凡情況，這些節點實現了IPv4優先級和[RFC791，RFC1812]
定義的轉發策略，但在其它方面是非分類業務兼容的。在[DSFIELD]中定義的等級選擇編碼點
（ClassSelectorCodepoints）被非凡考慮，保持與IPv4中TOS字節定義的優先值兼容，
同時，在[DSFIELD]中定義的等級選擇PHB也與[RFC791，RFC1812]定義的優先轉發行為
相兼容。遺留節點和分類業務兼容節點之間的要害區別在于，遺留節點可能，也可能不譯解
[RFC1349]定義的TOS字節的3-6比特（“DTRC”比特）；實際上它不會譯解[DSFIELD]
指定的那些比特。我們假設使用[RFC1349]中定義的TOS標記是被反對的。注重，那些不是
遺留節點的非分類業務兼容節點，在轉發帶有非零DS編碼點的數據包時，其轉發行為是不可
猜測的。
分類業務依靠于基于在節點上實現每一跳行為的資源分配機制。假如業務流穿過非分類業
務兼容節點或無分類業務能力域，那么服務的質量或統計確保水平很可能會下降。
我們討論兩種情況。第一種情況關于在DS域中使用非分類業務兼容節點。注重，PHB轉
發主要是在對稀有節點和鏈路資源進行有控制的分配時有用。在高速，輕載荷鏈路上，最壞包
延遲，抖動，和丟失都是可以忽略的，并且，在這樣的鏈路上游使用非分類業務兼容節點不會
造成服務降級。在多數實際情況下，一個節點缺少PHB轉發支持會導致無法對通過此節點的
數據流提供低時延，低丟包率服務，或預定服務帶寬。然而，假如在DS域中能夠僅使用
[DSFIELD]定義的等級服務編碼點，并且在遺留節點上的優先級實現方案與路徑上的其它節點
的轉發行為兼容，那么在無法兼容分類業務的節點處使用遺留節點就會是一個較好的替代方
案。注重，由于遺留節點可能，也可能不會根據[RFC1394]譯解第3-5比特，從而導致不可預
測的轉發行為，所以，必須限制只使用等級選擇編碼點。
第二種情況關于穿越無DS能力域（non-DS-capabledomain）的服務行為。出于討論
目的，我們假定無DS能力域不會在域邊界節點處進行業務量調節；因此，即便在域內存在遺
留節點或DS兼容節點的情況下，由于在邊界處缺少業務量治理，也會限制本域，使之不能穩
定提供某些服務。DS域和無DS能力域之間可以就如何在進入無DS能力域之前在DS域出
口處標記數據包達成協議。這個協議可通過業務量采樣而不是嚴格的業務量調節確保實施。如
果已知無DS能力域中包含遺留節點，那么上游DS域可以選擇將分類業務流重標記為一個或
多個等級選擇編碼點。假如對下游域的業務量治理能力一無所知，而且缺少域間協議，那么
DS出口節點可以選擇將DS編碼點重標記為零，并假設無DS能力域會平等對待所有業務
流，遵從盡力而為原則轉發。
在無DS能力域與DS域對等的情況下，來自無DS能力域的業務流應在DS域入口節點
處根據適當的SLA或其它協議進行調節。


5 關于組播
對組播業務使用分類業務機制引入很多問題。首先，在某個DS域入口節點進入的組播數
據包可能會被復制，然后通過多條不同的路徑穿越此DS域。這種情況下，組播業務就會比單
播業務消耗更多的網絡資源。由于組播成員是隨時變化的，因此很難猜測從上游網絡來的某一
組播業務會消耗本域的多少網絡資源。這種不確定性的后果之一就是很難向組播業務提供者提
供定量服務保證。此外，有必要為單播業務保留編碼點和PHB，以便提供不受組播干擾的資
源。
第二個問題是到達DS入口點的組播數據包如何選擇DS編碼點。組播數據包可能在多個
出口節點流出DS域，每個出口節點都對應一個下游DS域，和相應的SLA。應注重組播數據
包的編碼點不能違反任何一個SLA。當為從某一入口節點進入的請求分類服務的組播業務流建
立分類器和業務量調節器狀態時，應該考慮到相應的下游DS域標識和SLA細節（使之服從路
由策略及路由體系的穩定性）。這樣相應的下游DS域SLA可以部分的在上游DS域入口點處
得以履行，從而減輕上游域入口點的分類和業務量調節負擔。當然，在組播業務中采取這樣的
方法很困難，因為組播成員是動態變化的。結果是單播業務的服務保證會受到影響。解決此問
題的一種方案是，為組播業務創建單獨的SLA，并且或者讓組播業務采用非凡的一系列編碼
點，或者在DS出口點實現必要的分類和業務量調節機制，根據下游域SLA將單播業務優先分
離，提供服務。

6 安全和隧道問題
這一節主要討論由于引入分類業務而引起的安全問題，主要是拒絕服務攻擊隱患，和通過
未授權業務竊取服務隱患（參見6.1）。另外，在IPsec條件下分類業務的操作和與IPsec交
互問題也有討論（參見6.2節）。審查需求也在6.3節有所討論。本節討論的問題包括由
IPsec和非IPsec隧道引入的。

6.1 竊取和拒絕服務
分類業務的主要目的是在統一的網絡體系結構上，向業務流提供不同級別服務。很多資源
治理技術被用來完成這一目標，最終的結果是有些數據包會受到不同的（例如，更好的）服
務。把網絡業務映射到特定的行為集合從而取得不同的（或好或壞）服務，主要依靠設定DS
域。隨之而來的問題就是，可以通過把DS域修改為代表更高優先級的編碼點，或者直接注入
DS域置為這些編碼點的數據包而獲得更好的服務。在極端情況下，假如修改或者注入的數據
包耗盡了網絡資源，這種竊取服務行為就演變成拒絕服務攻擊。解決方案包括綜合使用在DS
邊界節點進行業務量調節和增強DS域內網絡結構的安全性和完整性。
如第2節描述，DS入口節點必須調節所有進入DS域的業務流，以確保它們帶有可接受
的DS編碼點。就是說編碼點必須符合適用的TCA和域服務提供策略。因此，入口節點是防止
基于修改DS編碼點（例如，改為此業務流無權的DS編碼點）的竊取和拒絕服務攻擊的主要
戰線。因為，任何這樣的攻擊都會違反TCA和/或服務提供策略。一種重要類型的入口節點是
在DS域中可以發起業務的節點。必須保證任何發起的業務都帶有可接受的DS編碼點。
域服務提供策略和TCA都可能要求入口節點改變某些流入數據包的DS編碼點（例如，
入口路由器可能根據適當的SLA設置用戶業務流的DS編碼點）。入口節點必須調節所有的業
務流以保證DS編碼點是可接受的；帶有不可接受編碼點的數據包必須或者被丟棄，或者將其
DS編碼點在轉發前改為可接受值。例如，入口節點可能會將從與之無增強業務協議的域收到
的業務流DS編碼點設置為缺省PHB編碼點[DSFIELD]。某些DS編碼點的適用可能需要特
別的業務授權（例如，那些對應于增強業務的編碼點），并且這類授權可以采用技術方法
（如，IPsec）和/或非技術方法（如，固定連接到唯一客戶的入口鏈路）。
域間協議可以使上游域部分或全部保證業務流帶有下游域可接受的DS編碼點，從而降低
入口節點進行業務量調節的要求。這種情況下，入口節點仍可以進行業務量調節檢查，以避免
對上游域的依靠（例如，這類檢查可以防止跨越域邊界傳播的竊取服務攻擊）。假如由于上游
域未能履行其責任，導致業務流未能通過入口節點檢查，那么這一審查事件必須被記錄；記錄
項包括接收到數據包的日期/時間，源和目的IP地址，和導致未通過此檢查的DS編碼點值。
實際中，需要在這類檢查的好處和它們對系統性能的影響之間做出權衡，確定到底哪些情況需
要檢查。
DS域內部節點依靠于DS段向要求分類業務功能的業務流提供服務。節點必須依靠正確
的DS域操作來防止帶有不可接受DS編碼點的業務流到達。健壯性考慮要求帶有不可接受
DS編碼點數據包的到達不會引起網絡節點癱瘓。內部節點沒有義務監督服務提供策略SLA的
執行情況，也不需要對DS編碼點進行檢查。內部節點可以對DS編碼點執行某些業務量調節
檢查（例如，檢查出在某條特定鏈路上從不會使用的編碼點），從而提高節點安全性和健壯性
（例如，可以防止基于DS編碼點修改的竊取服務攻擊）。任何檢查出的錯誤都是審查事件，
而應被記錄。記錄項包括接收到數據包的日期/時間，源和目的IP地址，和導致未通過此檢查
的DS編碼點值。實際中，需要在這類檢查的好處和它們對系統性能的影響之間做出權衡，確
定內部節點處到底需做哪些檢查。
假如一條鏈路不能充分保證其安全性，即是說，不能防止DS編碼點修改或者注入不合法
業務流，那么就應該被當作邊界連接對待（即，任何從此鏈路到達的業務流都象從入口節點處
進入DS域的業務流那樣進行各種檢查）。局部安全策略提供關于“充分安全”的定義。“充
分安全”定義中應給出一個DS編碼點修改和/或業務流注入的危險和后果，與對鏈路的采取額
外安全措施的平衡點。鏈路安全性可以通過物理接入控制和/或軟件方法，如確保數據包完整
性的隧道技術，得到提高。

6.2 IPsec和隧道交互
在IPsec協議中，如[ESP，AH]描述，不含有對IP頭DS段任何形式的加密（在隧道
中，外層IP頭的DS段未被加密）。因此，網絡節點對DS段的修改不會影響IPsec端到端的
安全性，因為這種修改不會引起IPsec完整性檢查失敗。其結果是，IPsec不能提供任何措施
防止對DS段的修改（如，中間人攻擊man-in-the-middleattach），因為攻擊者的修改不
會破壞IPsec的端到端完整性。在有些環境，這種修改DS段而不影響IPsec完整性檢查的能
力，可以組成一個隱蔽通道；假如有必要消除這樣的通道或減少其帶寬，可以把DS域配置
為，可以在業務流離開更高安全性域的DS出口節點處進行所需的處理（如，將敏感業務流的
所有DS段置為同一個值）。
IPsec的隧道模式為封裝的IP頭DS段提供了安全性支持。隧道模式下的IPsec包含有兩
個IP頭：由隧道入口節點提供的外層包頭和由數據包源節點提供的被封裝的內層包頭。當一條
IPsec隧道（部分或全部的）經過分類業務網絡時，中間的網絡節點會對外層包頭中的DS段
進行操作。在隧道出口節點處，IPsec會去掉外層包頭，并（假如需要）使用內層包頭轉發數
據包。假如內層IP頭沒有被隧道出口節點所在DS域的某個DS入口節點處理過，那么隧道出
口節點就作為離開隧道的業務流進入DS域的入口節點，也因此，此節點必須履行相應的業務
量調節策略（參見6.1節）。假如IPsec對所封裝數據包有足夠強壯的密碼完整性檢查（這里
的“足夠”取決于局部安全策略），那么隧道出口節點就可以安全的假設內層包頭的DS段值
與在隧道入口時相同。這就答應與隧道入口節點位于同一DS域的隧道出口節點，可以象對待
從同一DS域其它節點來的數據包一樣（即是說，省略DS入口節點業務量調節處理）處理從
隧道流出的數據包，并保證安全性。這樣做的一個重要后果就是，局部于DS域的其它不安全
鏈路可以使用足夠強壯的IPsec隧道使其安全。
此分析和隱含適用于任何進行完整性檢查的隧道協議，只是對內層包頭DS段的確保水平
依靠于隧道協議進行的完整性檢查力度。在隧道可能穿越當前DS域之外的節點時，假如缺少
對這類隧道足夠的信任，封裝的數據包就必須象對待從域外到達DS入口節點的數據包同樣處
理。
當前IPsec協議不答應在隧道出口節點處除IPsec封裝時改變內層包頭的DS段。這保證
了不能利用修改DS段的方法穿越IPsec隧道終點實施竊取服務或拒絕服務攻擊，因為任何這
類修改都會在隧道終點處丟棄。本文檔不對IPsec做任何修改。
假如IPsec的未來版本答應在隧道出口節點處根據外層包頭DS段值修改內層包頭DS段
值（例如，復制外層DS段的部分或全部內容到內層DS段），那么就還需對由此而來的安全
性問題額外考慮。當一條隧道完全處于一個DS域中，并且這條鏈路絕對安全，外層DS段不
會被修改，在修改內層DS段時的唯一限制來自于域服務提供策略。另外，進行這種修改的隧
道出口節點對流出隧道的業務流來說，應是DS入口節點，必須實施必要的業務量調節功能，
包括防止竊取服務和拒絕服務攻擊（參見6.1節）。假如隧道不是在其出口節點處進入DS
域，那么隧道出口節點就依靠上游的DS入口節點確保外層DS段值是可接受的。即使在這種
情況下，也有某些檢查是必須由隧道出口節點實施的（例如，加密隧道內層和外層DS段值一
致性檢查）。任何檢查出的錯誤都必須留有審查記錄，記錄內容包括數據包到達的日期/時
間，源和目的IP地址，和所攜帶的不可接收DS編碼點。
從體系結構角度，至少可以有兩種不同的方式看待IPsec隧道。假如隧道被看作邏輯上只
有一跳的“虛鏈路”，那么隧道中間節點轉發隧道中數據流的行為，對隧道終點來說就應該是
不可見的，并且在解除封裝過程中也不應該修改DS段值。相反的，假如隧道被看作是多跳
的，那么在隧道解除封裝的過程中修改DS段值，就是可以的了。后一種情況的具體例子如
下。隧道終止于DS域內部節點，而域治理者并不想在此節點安裝業務量調節功能（例如，為
了簡化業務量治理）。一種解決方案是，根據外層IP包頭的DS編碼點（根據此值在DS入口
節點處進行業務量調節）設置內層IP包頭DS編碼點。這樣就有效將業務量調節功能從IPsec
隧道出口節點轉移到了適當的上游DS入口節點（DS入口節點必須已經對未解除封裝的業務
流進行了業務量調節）。]

6.3 審查
并不是所有支持分類業務的系統都要實現審查功能。然而，假如分類業務支持融入了一個
提供審查功能的系統中，那么分類業務實現也必須支持審查。假如支持審查功能，那么就必須
答應系統治理者整體性的開啟或禁止分類業務審查功能，并且答應部分的開啟或禁止這類審
查。
大多數情況下，審查功能的粒度是局部問題。然而，本文檔中定義了一些審查事件，以及
每一事件記錄應包括的最小信息集。額外信息（如，引起此審查事件的數據包本身）也可被包
括在記錄信息中。并未在本文檔中提到的其他事件，也可以導致一條審查記錄。檢測到審查事
件后，并不要求接收者向發送者傳送任何的消息，因為回傳任何消息都有可能導致包括拒絕服
務攻擊在內的危險。

7 感謝
本文檔得益于早期由StevenBlake,DavidClark,EdEllesson,PaulFerguson,
JuhaHeinanen,VanJacobson,KaleviKilkki,KathleenNichols,WalterWeiss,John
Wroclawski,和LixiaZhang撰寫的初稿。
很多人為本文檔提供了有幫助的建議和意見，作者在此向他們表示感謝：KathleenNichols,
BrianCarpenter,KonstantinosDovrolis,ShivkumarKalyana,Wu-changFeng,MartyBorden,
YoramBernet,RonaldBonica,JamesBinder,BorjeOhlman,AlessioCasati,ScottBrim,Curtis
Villamizar,HamidOuld-Brahi,AndrewSmith,JohnRenwick,WernerAlmesberger,AlanO'Neill,
JamesFu,和BobBraden.

8 參考文獻
[802.1p]ISO/IECFinalCD15802-3Informationtechnology-
Telecommunicationsandinformationexchangebetweensystems-Localand
metropolitanareanetworks-Commonspecifications-Part3:MediaaccessControl
(MAC)bridges,(currentdraftavailableasIEEEP802.1D/D15).
[AH]Kent,S.andR.Atkinson,"IPAuthenticationHeader",RFC2402,
November1998.
[ATM]ATMTrafficManagementSpecificationVersion4.0<af-tm-0056.000>,
ATMForum,April1996.
[Bernet]Y.Bernet,R.Yavatkar,P.Ford,F.Baker,L.Zhang,K.Nichols,andM.
Speer,"AFrameworkforUSEOfRSVPwithDiff-servNetworks",WorkinProgress.
[DSFIELD]Nichols,K.,Blake,S.,Baker,F.andD.Black,"Definitionofthe
DifferentiatedServicesField(DSField)intheIPv4andIPv6Headers",RFC2474,
December，1998.
[EXPLICIT]D.ClarkandW.Fang,"ExplicitAllocationofBestEffortPacket
DeliveryService",IEEE/ACMTrans.onNetworking,vol.6,no.4,August1998,pp.
362-373.
[ESP]Kent,S.andR.Atkinson,"IPEncapsulatingSecurityPayload(ESP)",
RFC2406,November1998.
[FRELAY]ANSIT1S1,"DSSICoreaspectsofFrameRely",March1990.
[RFC791]Postel,J.,Editor,"InternetProtocol",STD5,RFC791,September
1981.
[RFC1349]Almquist,P.,"TypeofServiceintheInternetProtocolSuite",RFC
1349,July1992.
[RFC1633]Braden,R.,Clark,D.andS.Shenker,"IntegratedServicesinthe
InternetArchitecture:AnOverview",RFC1633,July1994.
[RFC1812]Baker,F.,Editor,"RequirementsforIPVersion4Routers",RFC1812,
June1995.
[RSVP]Braden,B.,Zhang,L.,BersonS.,Herzog,S.andS.Jamin,"Resource
ReSerVationProtocol(RSVP)--Version1FunctionalSpecification",RFC2205,
September1997.
[2BIT]K.Nichols,V.Jacobson,andL.Zhang,"ATwo-bitDifferentiatedServices
ArchitecturefortheInternet",FTP://ftp.ee.lbl.gov/papers/dsarch.pdf,November
1997.
[TR]ISO/IEC8802-5Informationtechnology-Telecommunicationsand
informationexchangebetweensystems-Localandmetropolitanareanetworks-
Commonspecifications-Part5:TokenRingAccessMethodandPhysicalLayer
Specifications,(alsoANSI/IEEEStd802.5-1995),1995.

9 作者聯系地址
StevenBlake
TorrentNetworkingTechnologies
3000AerialCenter,Suite140
Morrisville,NC27560

Phone:+1-919-468-8466x232
EMail:slblake@torrentnet.com

DavidL.Black
EMCCorporation
35ParkwoodDrive
Hopkinton,MA01748

Phone:+1-508-435-1000x76140
EMail:black_david@emc.com

MarkA.Carlson
SunMicrosystems,Inc.
2990CenterGreenCourtSouth
Boulder,CO80301

Phone:+1-303-448-0048x115
EMail:mark.carlson@sun.com

ElwynDavies
NortelUK
LondonRoad
Harlow,EssexCM179NA,UK

Phone:+44-1279-405498
EMail:elwynd@nortel.co.uk

ZhengWang
BellLabsLucentTechnologies
101CrawfordsCornerRoad
Holmdel,NJ07733

EMail:zhwang@bell-labs.com

WalterWeiss
LucentTechnologies
300BakerAvenue,Suite100
Concord,MA01742-2168

EMail:wweiss@lucent.com

10 完整版權聲明
Copyright?TheInternetSociety(1998)，版權所有。
本文件及其譯文可以復制并對外提供。可以部分或全部編著、復制、出版、分發與其有關
的評議、解釋和有助于實施的派生著作，沒有任何限制，但要求在復制文件和派生著作中包括
上述版權警告及本節版權聲明內容。但是，本文件的內容不答應做任何形式的修改，諸如刪除
版權警告或者關于InternetSociety或者其他Internet組織的介紹，除非為了開發Internet
標準或翻譯成英語以外的其他語言的需要，即使在這種情況下，也仍然必須遵循Internet標準
過程中確定的版權程序。
上述許可是永久性的，不會由TheInternetSociety，它的繼續者或轉讓者予以廢除。
本文件及其提供的信息以“現狀”為基礎，TheInternetSociety與IETF(因特網工程任
務小組)否認所有的保證實示或暗示，包含但并不限于任何保證。所含信息的使用將不會侵犯具
有非凡目的的商用性或者適用性的任何權利或隱含的保證。