Conta草案

ta在RFC3697中提出的對於IPv6流標籤的定義及使用。 在流標籤中前12位包含服務連線埠號，後8位包含主機之間的傳輸協定。 這種使用格式可以被DiffServ服務模型網路中流量調控器使用，根據前12位來尋找並獲取源連線埠和目的連線埠。

定義

由Conta在RFC3697中提出的對於IPv6流標籤的定義及使用。

格式

隨機值格式

這種格式要求流標籤被分配一個隨機的值。圖2-6(a)表示20個比特的標籤中第一個比特(從左至右)為0，剩餘19個比特是一個隨機數。當流標籤的第一位比特值為1時，標籤用於DiffServ網路模型如圖2-6(b)所示，相應的後19比特位值可以依照DiffServ網路模型中的產生相應的逐跳行為。服務提供商和用戶事先商定若干分類和為每種分類提供的服務，但是一個隨機值無法確定流屬於哪一類型。因此，攜帶的信息量不夠。

服務連線埠短格式

這種標籤格式，如圖2-7所示。在流標籤中前12位包含服務連線埠號，後8位包含主機之間的傳輸協定。分類器依然可以按照源地址、目的地址、源連線埠號、目的連線埠號和主機間協定來分類。在DiffServ服務模型機制中，多域流的分類和合併必須具有流的傳輸連線埠和傳輸協定，這種短格式包含了所需要的必要信息，因此DiffServ不需要另外輔助分類規則。這樣正好能和DiffServ服務模型機制中流的分類、流的合併策略吻合。但是簡化的比特數限制了連線埠的取值，12位只能標誌IANA所定義的從0到4095的常用連線埠子集。為了改進這種不足，提出了格式(3)。

服務連線埠長格式

傳輸層的TCP和UDP協定是目前網路上主機之間通信的僅有的兩種協定，因此可以把協定類型欄位減少為1個比特。前16位為網路服務端的連線埠標誌位，最後一個標誌位用來進行區分TCP或UDP協定類型，如圖2-8所示，三位Res預留為將來擴展之用，和上一種格式比較，用16位來表示連線埠，增加了3個比特位，十進制數值表示範圍擴大了16倍，幾乎可以滿足所有的連線埠值的套用。此方法的缺點跟上一種格式相同，即使流無法區分網路的兩個設備之間同一個套用的不同實例之間的通信，另外以末位一位比特來表示通信協定，使得協定的種類只限於兩種，對將來的擴展帶來很大的不便。

報頭長度格式

這種格式下，在流標籤中保存了Length of IPv6 Headers和跳到跳的協定。如圖2-9所示，流標籤的前12位十進制值包括了IPv6的基本頭和擴展頭部總長度。這種使用格式可以被DiffServ服務模型網路中流量調控器使用，根據前12位來尋找並獲取源連線埠和目的連線埠。此格式的長處是能依照流標籤中的前12位跳過IPv6所有的頭部位元組，徑直進入到網路層上層的傳輸層報頭頭部，這樣就可以支持那些非TCP、非UDP的沒有通信源、目的連線埠報文的分類。報頭長度格式的缺點是IPv6頭部本身沒有“所有頭部長度”欄位，所以在進行處理協定的時候，需要計算IPv6所有報頭長度，這就會增加協定的處理開銷。另外當IPv6套用ESP對載荷進行加密時該標籤中反映的頭部長度就沒有任何意義了，因此這種標籤格式的使用範圍有限。