IPV6首部的壓縮

馬光星

　　摘要:本文介紹了壓縮多個(gè)IP首部的方法。該方法能用于IPV6的基本首部和擴(kuò)展首部,TCP和UDP首部，IPV4首部和封裝的IPV6及IPV4首部。典型的UDP和TCP包的首部能壓縮到4-7個(gè)字節(jié),包括2個(gè)字節(jié)UDP或TCP校驗(yàn)和。這樣就去掉了較大IP首部的很多負(fù)面影響并允許在低速和中速鏈路上有效地使用帶寬。該壓縮算法專為有一定包丟失率的鏈路設(shè)計(jì)的。如,無(wú)線鏈路和使用調(diào)制解調(diào)器的鏈路。

　　關(guān)健詞：首部，壓縮，鏈路，IPV6，TCP，UDP。

1.引言

　　在低速和中速鏈路上進(jìn)行首部壓縮能起到如下作用：

(1)減少互動(dòng)響應(yīng)時(shí)間

　　對(duì)于很低速的鏈路,由于發(fā)送大的首部需要時(shí)間,字符的返回時(shí)間可能大于100-200ms。100-200ms是人們能夠容忍的感覺不到系統(tǒng)遲緩的最長(zhǎng)時(shí)間。

(2)允許用較小的包傳送大量數(shù)據(jù)有好的線路效率

　　當(dāng)互動(dòng)(如,Telnet)和大量業(yè)務(wù)(如,FTP)混合時(shí),由于在小包里載大量數(shù)據(jù),在大量數(shù)據(jù)包后,捕獲帶互動(dòng)數(shù)據(jù)的包時(shí),減少了等待時(shí)間。在此情況下,對(duì)于FTP業(yè)務(wù)使用長(zhǎng)度小的包,全部解決本地問題。當(dāng)處理很多小包時(shí),將減少網(wǎng)上的負(fù)載。更好的解決方法是在較慢的鏈路上將大包分段。

(3)對(duì)時(shí)延敏感的低速數(shù)據(jù)業(yè)務(wù)允許用較小的包

　　對(duì)于此應(yīng)用,如,語(yǔ)音,如果包很大,用數(shù)據(jù)填充包的時(shí)間是重要的。要得到較低的端到端時(shí)延,小包是優(yōu)越的。未壓縮首部,最小可能的IPV6/UDP首部長(zhǎng)48個(gè)字節(jié),用每秒50包的速率消耗19.2kbit/s。每秒50包相當(dāng)于在每個(gè)包中有20ms的語(yǔ)音取樣值。如,支持移動(dòng)的遂道或路由首部將增加首部的帶寬消耗10-20kbit/s。如,用GSM編碼的13 kbit/s,與實(shí)際語(yǔ)音取樣需要的帶寬相比較,壓縮能有效地減少需要的帶寬約1.7kbit/s。這能使更高質(zhì)量的語(yǔ)音在14.4kbit/s和28.8kbit/s modems上傳輸。

(4)減少首部開銷

　　在中速鏈路上大量傳送的TCP分段的通用長(zhǎng)度今天是512個(gè)字節(jié)。例如,由于使用移動(dòng)IP,在隧道方式中,TCP分段的IPV6/IPV6/TCP首部是100字節(jié)。首部壓縮將減少首部的開銷,對(duì)于IPV6/TCP,從19.5 %減少到小于1%。對(duì)于線路速度這是重要的增益,高達(dá)幾 mbit/s。IPV6規(guī)范規(guī)定了路徑MTU(Maximum Transmission Unit)發(fā)現(xiàn),因此,用IPV6大量傳送大于512字節(jié)的TCP分段。直到用1400字節(jié)的分段(RFC 894以太網(wǎng)封裝允許1500字節(jié)的凈載荷,其中100字節(jié)用于IP首部),首部壓縮減少了IPV6首部的開銷從7.1%到0.4%。

(5)在有丟失的鏈路上減少包的丟失率

　　由于每個(gè)包只發(fā)送較少比特,對(duì)于給定的差錯(cuò)率,包的丟失率將是較小的。在此描述的機(jī)理,用于點(diǎn)到點(diǎn)鏈路,但允許擴(kuò)展到多路接入鏈路和組播。對(duì)于TCP包,文件[5]的機(jī)理用于從丟失中恢復(fù)。兩個(gè)附加的機(jī)理增加了在有丟失的鏈路上,首部壓縮的效率。對(duì)于非TCP包,壓縮緩慢地開始和周期地刷新,改變上下關(guān)系的首部丟失后,允許拋棄包的周期最小。

2.壓縮原理和方法

　　首部壓縮依靠很多字段不變或在同一包流的相鄰包之間很少改變。兩個(gè)包之間不改變的字段都不需要發(fā)送。常有小的改變或可預(yù)測(cè)的值,如,TCP的順序號(hào)能用增量編碼,因此,對(duì)于這樣的字段需要的比特?cái)?shù)大量減少。只有常常改變和隨機(jī)的字段,如,校驗(yàn)和或認(rèn)證數(shù)據(jù),需要在每個(gè)首部中發(fā)送。首部壓縮的普遍原理是偶爾發(fā)送一個(gè)有全首部的包；隨后的壓縮首部參考由全首部建立的上下關(guān)系和上下關(guān)系可能包含的增量改變。首部壓縮方案不需要在相同包流中的所有包的首部通過壓縮鏈路。然而,對(duì)于TCP包流,兩個(gè)隨后首部之間的差別可能變的更不規(guī)則并能減少壓縮率。

　　該首部壓縮方案在第一跳或最后一跳以及網(wǎng)絡(luò)中間鏈路上都是有用的。當(dāng)很多包流(幾百個(gè))跨越鏈路時(shí),被叫做CID(context identifier)的波動(dòng)現(xiàn)象可能發(fā)生,在首部很少能夠與現(xiàn)存的上下關(guān)系匹配的地方,則必須發(fā)送不壓縮的全首部。

　　對(duì)于非TCP包流幾乎首部的所有字段都是常數(shù)。TCP的很多字段是常數(shù)和其他變化小,可預(yù)測(cè)的值。要開始包流的首部壓縮,在鏈路上發(fā)送載有(CID)的全首部。壓縮器和解壓器存儲(chǔ)全首部的大多數(shù)字段作為上下關(guān)系。上下關(guān)系是由首部的常值字段(不需要在鏈路上全部發(fā)送)或兩相鄰首部之間改變很小(因此,只用幾個(gè)比特發(fā)送與前面發(fā)送的絕對(duì)值的差)的字段組成。

　　在包流中常值字段的任何改變,將引起壓縮器發(fā)送全首部,更改解壓器的上下關(guān)系。只要在壓縮器和解壓器中的上下關(guān)系相同,就能精確地恢復(fù)為壓縮前的首部。然而,如果全首部或壓縮首部在傳輸中有丟失,解壓器的上下關(guān)系若不作適當(dāng)修改可能過時(shí)。將不能正確地恢復(fù)首部。

2.1.包的類型

　　該壓縮方法使用除IPV6外4種類型的包。鏈路層包的類型和包中前4比特值的結(jié)合唯一的確定包的類型。FULL-HEADER--是指有未壓縮首部的包,包括一個(gè)CID和(若非TCP首部)一個(gè)代“G”(generation)。對(duì)于由CID識(shí)別的包流,它能建立或刷新上下關(guān)系。 COMPRESSED-NON-TCP--是指有壓縮首部的非TCP包。壓縮首部由一個(gè)CID(識(shí)別解壓使用的上下關(guān)系),G(檢測(cè)不一致的上下關(guān)系)和首部的隨機(jī)變化的字段組成。COMPRESSED-TCP--是指有壓縮TCP首部的包,包含一個(gè)CID,一個(gè)識(shí)別改變字段的標(biāo)志字節(jié)和改變字段與前面值差的編碼。

COMPRESSED-TCP-NODELTA--是指有壓縮TCP首部的包,正常發(fā)送所有字段,當(dāng)與前面的值不同時(shí),發(fā)送as-is代替。只在響應(yīng)來(lái)自解壓器的首部請(qǐng)求時(shí)發(fā)送這類包。當(dāng)作為重傳結(jié)果時(shí)不必發(fā)送它。

2.2.TCP包流中丟失包時(shí)

　　因?yàn)槭褂门c前面TCP首部的差異壓縮TCP首部,丟失一個(gè)壓縮首部或全首部,由于解壓使用的上下關(guān)系沒有適當(dāng)?shù)卦黾?將引起以后壓縮的首部不能正確的解壓。一個(gè)壓縮TCP首部的丟失將引起以后解壓的TCP首部的順序號(hào)k次中斷,k是丟失段的數(shù)量。當(dāng)TCP校驗(yàn)和可靠的捕獲到順序號(hào)"off-by-k"次差錯(cuò)時(shí),TCP接收器丟棄不正確解壓的TCP首部的包。TCP的修復(fù)機(jī)理實(shí)際上是重發(fā)丟失的分段并且當(dāng)重發(fā)時(shí),壓縮器檢測(cè)TCP首部。假設(shè)重發(fā)是由于解壓器的壓縮狀態(tài)失配,壓縮器重發(fā)全首部。在有較高丟失率的中速鏈路上這是重要的,如,無(wú)線。在鏈路上不可接收的包丟失后,由于上下關(guān)系不一致,丟棄超時(shí)的包。

2.3.在UDP和其他非TCP 包流中丟失包時(shí)

　　UDP包和其他非TCP包(象TCP包一樣)由于校驗(yàn)和沒有很好地保護(hù),不能正確的解壓。沒有變成“ off-by-k”的順序號(hào)和實(shí)際校驗(yàn)和保護(hù)失敗。UDP校驗(yàn)和只包含凈載荷,UDP首部和偽首部。偽首部包括源地址和目的地址,傳輸協(xié)議類型和包的長(zhǎng)度。除這些字段外,UDP校驗(yàn)和不包含IPV6首部的大部分。然而,其他非TCP首部缺乏完整的校驗(yàn)和,如,分段首部。

　　為了避免非TCP首部的不正確解壓,用G識(shí)別非TCP包流的上下關(guān)系的每個(gè)版本,G是由建立和刷新上下關(guān)系的全首部攜帶的一個(gè)小數(shù)碼。壓縮首部攜帶用于解壓的上下關(guān)系的G值。當(dāng)解壓器注意到壓縮首部攜帶一個(gè)G值而不是包流的上下關(guān)系的G時(shí),上下關(guān)系未到期而必須丟棄或存儲(chǔ)該包,直到全首部建立起正確的上下關(guān)系。對(duì)于非TCP包流用相同的編碼,壓縮非TCP首部不改變上下關(guān)系。因此,一個(gè)壓縮首部丟失以后,帶有壓縮首部的包仍然有效。只有當(dāng)全首部的上下關(guān)系與前面的全首部的上下關(guān)系不同時(shí)這個(gè)G才改變。意思是只有全首部實(shí)際改變上下關(guān)系時(shí),丟失一個(gè)全首部將使解壓器的上下關(guān)系過時(shí)。

　　G字段占6比特,因此,G值重復(fù)64次后,就改變上下關(guān)系。要避免差錯(cuò)突發(fā)或其他臨時(shí)破壞后不正確的解壓,在MIN-WRAP秒后,壓縮器一定不能再用相同的G值。拆除解壓器MIN-WRAP秒或更多時(shí),解壓前必須等待下一個(gè)全首部。驅(qū)動(dòng)后,壓縮非TCP首部前,壓縮器必須至少等待MIN-WRAP秒。壓縮器改變另一個(gè)CID或發(fā)送規(guī)則的首部要經(jīng)過MIN-WRAP秒后。

2.3.1.壓縮緩慢開始

　　要允許解壓器從改變上下關(guān)系的一個(gè)全首部的丟失中快速恢復(fù),在上下關(guān)系改變后,按指數(shù)增量周期地發(fā)送全首部。這項(xiàng)技術(shù)避免了其它壓縮方案使用的壓縮器和解壓器之間消息的交換。壓縮器保持每個(gè)非TCP包流的一個(gè)變量,F-PERIOD保持追蹤兩個(gè)全首部之間可發(fā)送多少個(gè)壓縮首部。當(dāng)非TCP包流的首部改變時(shí),因此,它的上下關(guān)系改變,發(fā)送一個(gè)全首部和F-PERIOD置1。在壓縮緩慢開始時(shí),每次發(fā)送一個(gè)全首部要兩倍F-PERIOD。

2.3.2.周期的首部刷新

　　如果接收器丟失了上下關(guān)系要避免丟失太多的包,有一個(gè)上限F-MAX-PERIOD,在兩次首部刷新之間,可以發(fā)送的有壓縮首部的非TCP包的數(shù)量。如果發(fā)送該包流的最后一個(gè)全首部后,發(fā)送了F-MAX-PERIOD壓縮首部,必須發(fā)送一個(gè)全首部。對(duì)于低數(shù)據(jù)速率的包流要避免長(zhǎng)期拆線,也有一個(gè)上邊界F-MAX-TIME,在非TCP包流中兩個(gè)全首部之

間的時(shí)間。自從發(fā)送一個(gè)全首部后,如果對(duì)此包流發(fā)送一個(gè)包的傳輸時(shí)間超過F-MAX-TIME秒,必須發(fā)送全首部。

2.3.3.發(fā)送全首部的規(guī)則

　　當(dāng)對(duì)非TCP包流發(fā)送全首部時(shí),由壓縮器決定能使用的下列偽編碼。編碼維持兩個(gè)變量：

　　C-NUM--自從最后的全首部發(fā)送后,發(fā)送壓縮首部的計(jì)數(shù)。

　　F-LAST--發(fā)送最后全首部的時(shí)間。

　　和使用功能current-time()返回當(dāng)前時(shí)間min(a,b)

返回最小的a和b

send-full-header過程(),increment-generation-value()和send-compressed-header(),明顯要做的事。

If(〈該首部改變上下關(guān)系〉)

C-NUM:=0；

F-LAST:=current-time();

F-PERIOD:=1;

increment-generation-value();

send-full-header();

else if(C-NUM≧F-PERIOD)

C-NUM:=0

F-LAST:=current-time();

F-PERIOD:=min(2*F-PERIOD,F-MAX-PERIOD);

Send-full-header();

else if(current-time()>F-LAST+F-MAX-TIME)

c-num:=0;

F-LAST:=current-time();

Send-full-header();

else

c-num:=C-NUM+1;

Send-compressed-header();

end if

3.組織包進(jìn)入包流

　　什么樣的包可以組織在一起進(jìn)入壓縮的包流。要達(dá)到最好的壓縮率,同一包流中有類似首部的包應(yīng)該組織在一起。如果組織失敗,壓縮首部的性能將變壞,因?yàn)閴嚎s算法能夠利用的包流中現(xiàn)存的上下關(guān)系很少而必須頻繁地發(fā)送全首部。壓縮器可以用任何準(zhǔn)則適當(dāng)?shù)慕M織包進(jìn)入包流。確定一個(gè)包屬于什么包流,壓縮器可以1)檢驗(yàn)可壓縮的子首部鏈,2)檢驗(yàn)跟著可壓縮子首部鏈的上層協(xié)議首部的內(nèi)容,如,ICMP部首或隧道的IPX首部,3)利用從資源管理者得到的信息,如果,資源管理者請(qǐng)求對(duì)特定包流進(jìn)行壓縮并提供識(shí)別包屬于哪個(gè)包流的方法,4)利用其他任何相關(guān)信息,如果,在一個(gè)包流中的選路標(biāo)志和跳數(shù)限制字段在n和n+k之間頻繁地改變,壓縮器可以組織包進(jìn)入兩個(gè)不同的包流。

　　壓縮器不能自由的組織包進(jìn)入壓縮的包流,讓一些包保持它們的規(guī)則首部和不修改地傳送。只要非TCP包流遵循發(fā)送全首部時(shí)的規(guī)則和按規(guī)定壓縮子首部,解壓器能夠正確地重組壓縮首部,不考慮怎樣組織包進(jìn)入包流。

組織包的準(zhǔn)則在此給出壓縮器怎樣組織包進(jìn)入壓縮包流的選擇準(zhǔn)則。

　　定義字段

　　同一包流中不同包之間相同的首部字段為定義字段,用DEF作為定義字段的標(biāo)記。定義字段包括流標(biāo)簽,IP首部的源和目的地址,在路由首部中的最終目的地址,下一首部字段,口編號(hào)(UDP和TCP)和在認(rèn)證及加密首部中的安全參數(shù)索引(SPI)。

　　分段包

　　分段包和未分段包決不能組織在同一包流中。分段首部的標(biāo)識(shí)字段不應(yīng)該用于識(shí)別包流。如果這樣,新包的一個(gè)分段將引起壓縮的緩慢啟動(dòng)。

　　上層協(xié)議標(biāo)識(shí)

　　為標(biāo)識(shí)包流,應(yīng)該用識(shí)別首部的第一個(gè)下一首部字段,即,有相同DEF字段和相同上層協(xié)議的所有包應(yīng)該組織在一起。

　　跳數(shù)限制字段

　　成熟實(shí)現(xiàn)可能監(jiān)視跳數(shù)限制字段和用它作為DEF字段時(shí),它是否頻繁地改變。當(dāng)有頻繁的選路標(biāo)記時(shí)可能出現(xiàn),因此,包通過不同路徑跨越因特網(wǎng)。

　　業(yè)務(wù)等級(jí)字段

　　IPV6首部的業(yè)務(wù)等級(jí)字段,在有其他相同DEF字段的包之間可能頻繁地改變。成熟地實(shí)現(xiàn)應(yīng)該注意到這點(diǎn)并準(zhǔn)備用這些字段作為定義字段。

　　當(dāng)IP包在隧道方式時(shí),在隧道的入口點(diǎn)用一個(gè)附加的IP首部封裝他們并發(fā)送到隧道的終點(diǎn)。要組織這樣的包進(jìn)入包流,應(yīng)檢驗(yàn)內(nèi)部首部確定包流。如果不這樣做,每次內(nèi)部IP包的首部改變都將發(fā)送全首部。當(dāng)包在隧道方式時(shí),除識(shí)別初始IP字段外,應(yīng)該考慮識(shí)別內(nèi)部子首部字段一個(gè)實(shí)現(xiàn)能用其它字段標(biāo)識(shí),如果用太多的字段標(biāo)識(shí),由于將用更多的CIDs和當(dāng)新的包流需要CIDs時(shí),可能用錯(cuò)誤的CIDs,性能可能受到損害。如果用太少的字段標(biāo)識(shí),由于太頻繁地改變上下關(guān)系,性能也可能受到損害。

4.長(zhǎng)度問題

4.1.上下關(guān)系標(biāo)識(shí)符(CID)

　　(CID)可能是8比特或16比特。他們的長(zhǎng)度與發(fā)現(xiàn)上下關(guān)系無(wú)關(guān)。8比特CID的數(shù)值2和16比特CID的數(shù)值2是等效的。TCP和非TCP的CID空間是分開的,因此,即使它們有相同的值,TCP CID和非TCP CID決不視為相同的上下關(guān)系。當(dāng)用相同的CIDs比特?cái)?shù)時(shí),這是雙倍可用的CID空間。對(duì)于TCP或非TCP總是可以識(shí)別全首部或壓縮首部,因此,不會(huì)混肴。

　　對(duì)于非TCP包, 8比特CID允許2個(gè)字節(jié)的最小壓縮首部長(zhǎng)度,CID用第一字節(jié),長(zhǎng)度比特和6個(gè)比特G值填入第二字節(jié)。對(duì)于TCP,CID的長(zhǎng)度只能用8個(gè)比特。當(dāng)TCP連接點(diǎn)到點(diǎn)時(shí)8個(gè)比特是足夠的。對(duì)于點(diǎn)到點(diǎn)鏈路,CID的長(zhǎng)度不必用16比特；要用于多接入鏈路,為了CID的有效的選擇,可能需要較大的CID空間。

　　多接入鏈路的主要困難是幾個(gè)壓縮器共享一個(gè)解壓器的CID空間。當(dāng)沖突可能發(fā)生時(shí),壓縮器不能再獨(dú)立地選擇CID。每個(gè)壓縮器有一個(gè)獨(dú)立的CID空間可以解決這個(gè)問題。有獨(dú)立的CID空間,要求解壓器能識(shí)別哪個(gè)壓縮器發(fā)送的壓縮包,也許可用鏈路層信息,如,誰(shuí)發(fā)送的鏈路層幀。如果,這樣的信息不能用,可以自動(dòng)列舉在多接入鏈路上的所有壓縮器和提供它們的編號(hào)作為CID的部分。后一種方法需要大的CID空間。

4.2.上下關(guān)系的長(zhǎng)度

　　壓縮器和解壓器簡(jiǎn)單地實(shí)現(xiàn)及它們的存儲(chǔ)器要求,應(yīng)當(dāng)限制上下關(guān)系的長(zhǎng)度。然而,當(dāng)擴(kuò)展首部鏈的長(zhǎng)度任意時(shí),IPV6首部的長(zhǎng)度沒有上限。當(dāng)上下關(guān)系基本上是一個(gè)存儲(chǔ)的首部時(shí),這是一個(gè)問題�？膳渲玫膮�數(shù)MAX-HEADER代表上下關(guān)系的最大長(zhǎng)度,表示能夠存儲(chǔ)的最長(zhǎng)首部作為上下關(guān)系。當(dāng)一個(gè)首部大于MAX-HEADER時(shí),只存儲(chǔ)它的一部分作為上下關(guān)系。一次實(shí)現(xiàn)不必壓縮大于一個(gè)首部的初始MAX-HEADER字節(jié)。一次實(shí)現(xiàn)不必部分地壓縮一個(gè)子首部。作為上下關(guān)系存儲(chǔ)的和壓縮首部的部分是最長(zhǎng)的整個(gè)子首部的初始序列,不大于MAX-HEADER字節(jié)。

4.3.全首部的長(zhǎng)度

　　當(dāng)對(duì)于鏈路的MTU可以優(yōu)化他們的長(zhǎng)度時(shí),避免增加全首部包的長(zhǎng)度超過他們的原長(zhǎng)度。因此,我們假設(shè)鏈路層實(shí)現(xiàn)提供包的長(zhǎng)度,我們能用全首部中的長(zhǎng)度字段傳遞CID和G值到解壓器。要求鏈路層不必對(duì)凈載荷加填充,至少?zèng)]有能夠傳送到鏈路上目的用戶的填充。還要求在UDP數(shù)據(jù)后或隧道中的包不加額外的填充。允許從首部的長(zhǎng)度和鏈路層幀的長(zhǎng)度計(jì)算長(zhǎng)度字段的值。

　　G需要1個(gè)字節(jié)和CID需要2個(gè)字節(jié)。在IPV6基本首部和UDP首部中有2個(gè)字節(jié)長(zhǎng)度字段。在IP首部中,全TCP首部至少有2個(gè)字節(jié)可用,足夠傳送8比特CID。如果,多于1個(gè)IP首部將有2個(gè)以上字節(jié)可用。當(dāng)IPV6擴(kuò)展首部的順序不固定和CID值不能與下一首部字段的合法值分離時(shí),我們不能使用相應(yīng)的方法。

　　一個(gè)IPV6/UDP包將有4個(gè)字節(jié)可用于傳送G和CID,因此,可以使用全部CID長(zhǎng)度。分段和加密包流可能只有2個(gè)字節(jié)可用于傳送G和CID。對(duì)于這樣的包流8比特CIDs可能只用于CID長(zhǎng)度。當(dāng)IPV6用于隧道方式時(shí),至少將有4個(gè)字節(jié)可用并可用兩個(gè)CID長(zhǎng)度字段。在全首部中第一個(gè)長(zhǎng)度字段的高字節(jié)傳送G值。當(dāng)只有一個(gè)長(zhǎng)度字段可用時(shí),在低字節(jié)中傳送8比特CID。當(dāng)兩個(gè)長(zhǎng)度字段可用時(shí),在第二長(zhǎng)度字段中傳送CID的最低2個(gè)字節(jié)和第一長(zhǎng)度字段的低字節(jié)攜帶CID的最高字節(jié)。

4.3.1.在全TCP首部中長(zhǎng)度字段的使用

第一長(zhǎng)度字段的使用：

長(zhǎng)度字段 LSB of okt nr CID

若可用,第二長(zhǎng)度字段的使用:

第二長(zhǎng)度字段 LSB of okt nr CID

pkt nr是短包的順序號(hào)。

4.3.2.在非TCP全首部中長(zhǎng)度字段的使用

有8比特CID的非TCP全首部:

第一長(zhǎng)度字段

O D Generation CID

第二長(zhǎng)度字段(若可用)

O Data(if D=1)

有16比特CID的非TCP全首部:

第一長(zhǎng)度字段

1 D Generation Data (if D=1)

第二長(zhǎng)度字段

CID

第一長(zhǎng)度字段的第一比特表示CID的長(zhǎng)度。若D是0,數(shù)據(jù)字段是0。

5.壓縮首部的格式

a)壓縮TCP的形式(類似于文件)：

　　在第二字節(jié)中后面的標(biāo)記(IPSAWU)與文件中的意思相同,不考慮IPV6是否攜帶TCP分段。與CID有關(guān)的上下關(guān)系保持追蹤IP版本和出現(xiàn)什么RANDOM字段。一次實(shí)現(xiàn)將從開始搜索上下關(guān)系和按順序插入的RANDOM字段。當(dāng)他們?cè)谠�未壓縮的首部中按相同順序出現(xiàn)時(shí),RANDOM字段放在TCP首部的DELTA字段之前。

　　I標(biāo)記是0,表示TCP前面的首部不是IPV4。如果O標(biāo)記置1,TCP首部的選項(xiàng)不同于前面的首部。整個(gè)選項(xiàng)字段放在壓縮TCP首部的最后面。如果R標(biāo)記置1,在上下關(guān)系和TCP首部中的保留字段(6個(gè)比特)或緊接TCP前面的IPV6首部中業(yè)務(wù)等級(jí)字節(jié)的比特6或比特7之間有差別。有保留字段和業(yè)務(wù)等級(jí)字段的比特6和比特7的實(shí)際值的一個(gè)字節(jié)放在緊跟RANDOM字段的后面。傳送字節(jié)的比特0-5是保留字段的實(shí)際值,比特6和比特7是在業(yè)務(wù)等級(jí)字段中比特6和7的實(shí)際值。如果沒有前面的IP首部,比特6和比特7是0。傳送有R標(biāo)記的字節(jié)不必更新上下關(guān)系。注意：R字節(jié)不更新上下關(guān)系,如果它更新了上下關(guān)系,nTCP校驗(yàn)和不保護(hù)從錯(cuò)誤的解壓首部接收的TCP。由于顯式擁塞通知希望頻繁地改變業(yè)務(wù)等級(jí)字節(jié)比特6和比特7。

b)壓縮TCP-NODELTA首部的格式

c)壓縮非TCP首部,8比特CID：

d)壓縮非TCP首部,16比特CID：

當(dāng)壓縮狀態(tài)隱含時(shí),G,CID和一個(gè)字節(jié)選項(xiàng)的數(shù)據(jù)跟著是相關(guān)的RANDOM字段,當(dāng)在原未壓縮首部中出現(xiàn)時(shí),按相同順序存放,跟著是凈載荷。

6.子首部的壓縮

　　在此給出必須遵守的壓縮子首部鏈的規(guī)則�？梢詨嚎s的子首部包括IPV6基本和擴(kuò)展首部,TCP首部,UDP首部�？蓧嚎s的子首部鏈從首部的開始處擴(kuò)展。

　　a)達(dá)到但不包括第一首部不是IPV6基本或擴(kuò)展首部,TCP首部或UDP首部或

　　b)達(dá)到并包括第一TCP首部,UDP首部,分段首部,封裝安全凈載荷首部。

　　任何給定較短的鏈。如,規(guī)則a)和b)都填在一個(gè)子首部鏈中包括分段首部和在隧道末端的IPX包。因此,規(guī)則b)給一個(gè)較短的鏈,可壓縮的子首部鏈在分段首部停止。NOCHANGE不希望改變的字段。任何改變都必須發(fā)送全首部更新上下關(guān)系。DELTA可以經(jīng)常改變的字段,但通常與前面首部中的字段差別較小,因此,發(fā)送前面值的改變而不是當(dāng)前值。這類壓縮只用于TCP包流。

　　RANDOM 在壓縮首部中的該字段必須包括“as-is”,通常由于是不可預(yù)測(cè)的改變。

　　INFERRED 該字段包含能從其它數(shù)值推測(cè)的數(shù)值,如,幀長(zhǎng)度不必包含在壓縮首部中。

　　分類指的是怎樣構(gòu)造壓縮首部。在壓縮首部中不出現(xiàn)NOCHANGE或INFERRED字段。壓縮器從壓縮標(biāo)識(shí)符識(shí)別上下關(guān)系得到NOCHANGE字段和從鏈路層實(shí)現(xiàn)得到INFERRED字段,如,從鏈路層的幀長(zhǎng)度或從其它字段。在同一包流中與前面包的值不同時(shí),編碼為DELTA字段。壓縮器必須更新上下關(guān)系,在壓縮首部中上下關(guān)系數(shù)值上加適當(dāng)?shù)臄?shù)值,得到字段的適合值。在壓縮首部中的RANDOM字段必須發(fā)送“as-is”。當(dāng)他們?cè)谌�首部中出現(xiàn)時(shí),在壓縮首部中的RANDOM字段必須按相同的順序出現(xiàn)�？蛇x擇的字段用于識(shí)別有DEF標(biāo)記的包屬于什么包流。使用選項(xiàng)準(zhǔn)則的壓縮器,在兩個(gè)包之間相應(yīng)的DEF字段有任何不同,意味著它們屬于不同的包流。然而,如果DEF字段在一個(gè)包中出現(xiàn)而在另一個(gè)包中不出現(xiàn),這兩個(gè)包屬于不同的包流。

6.1.IPV6首部

版本不變(NOCHAGE)(DEF)

業(yè)務(wù)等級(jí) 不變(NOCHAGE) (可能是DEF)

流標(biāo)簽不變(NOCHAGE)(DEF)

凈載荷長(zhǎng)度 推測(cè) (INFERRED)

下一首部 不變(NOCHAGE)

跳數(shù)限制 不變(NOCHAGE)(可能是DEF)

源地址不變(NOCHAGE)(DEF)

目的地址 不變(NOCHAGE)(DEF)

　　封裝首部的凈載荷長(zhǎng)度字段必須相應(yīng)于封裝首部的長(zhǎng)度值。否則一定不能壓縮。

　　注意：如果IP首部最接近TCP首部,用壓縮TCP首部的R標(biāo)記能夠傳送業(yè)務(wù)等級(jí)字段的比特7。這樣的分類意味著整個(gè)IPV6基本首部將被壓縮掉。

6.2.IPV6的擴(kuò)展首部和選項(xiàng)

　　在包流中出現(xiàn)什么擴(kuò)展首部和它們的相對(duì)順序希望不變。在任何時(shí)間有改變,就必須發(fā)送全首部的包。在IPV6基本首部和擴(kuò)展首部中所有下一首部字段都不變。Hop-by-Hop選項(xiàng)和目的地址選項(xiàng)擴(kuò)展首部的內(nèi)容用TLV(Type-Length-Value)“選項(xiàng)”編碼:選項(xiàng)類型 選項(xiàng)數(shù)據(jù)長(zhǎng)度 選項(xiàng)數(shù)據(jù)

　　對(duì)于給定包流中的選項(xiàng)類型和選項(xiàng)數(shù)據(jù)長(zhǎng)度字段假設(shè)是固定的,因此,它們屬于不變的類型。選項(xiàng)數(shù)據(jù)是隨機(jī)的除非另有規(guī)定。

填充1選項(xiàng)

0

整個(gè)選項(xiàng)不變。

填充N選項(xiàng)

1 選項(xiàng)數(shù)據(jù)長(zhǎng)度 選項(xiàng)數(shù)據(jù)

所有字段都不變。

6.3.Hop-by-Hop選項(xiàng)首部

下一首部不變

首部擴(kuò)展長(zhǎng)度不變

選項(xiàng)TLV編碼值和填充不變。

巨大凈載荷選項(xiàng)

　　前兩個(gè)字段不變和巨大凈載荷長(zhǎng)度可推測(cè)。(必須由鏈路層實(shí)現(xiàn)提供幀長(zhǎng)度)。

　　注意：壓縮攜帶巨大凈載荷選項(xiàng)包的首部是不必要的,因?yàn)槭撞康南鄬?duì)開銷是可忽略的。然而,在低和中速鏈路上發(fā)送這樣大的包通常是不現(xiàn)實(shí)的。

6.4.路由首部

　　路由首部的所有字段都不變。如果不能識(shí)別路由首部,不可能確定最終目的地址,除非分段剩余字段是0,在此情況下目的地址是基本IPV6首部中的最終目的地址。在類型0路由首部中,最后地址是DEF(如果分段剩余>0)。路由首部全部壓縮掉。當(dāng)路由首部的最大長(zhǎng)度是392字節(jié)時(shí),這是很大的勝利。然而,類型0路由首部有一個(gè)24字節(jié)的地址用于移動(dòng)IP。

6.5.分段首部

分段首部的分類如下：

下一首部不變

保留不變

Res隨機(jī)

M標(biāo)記隨機(jī)

分段偏移量隨機(jī)

標(biāo)識(shí)隨機(jī)

　　這樣的分類意味著分段首部壓縮6個(gè)字節(jié)。最小IPV6的MTU是1280字節(jié),因此,大多數(shù)分段至少是1280字節(jié)。壓縮分段首部只減少6個(gè)字節(jié)的開銷,分?jǐn)傇诤艽蟮陌��?另外需要更復(fù)雜的綜合壓縮方案,壓縮分段首部是不值的。

6.6.目的地址選項(xiàng)首部

下一首部不變

首部擴(kuò)展長(zhǎng)度不變

選項(xiàng)TLV編碼值和填充不變。

6.7.認(rèn)證首部

下一首部不變

長(zhǎng)度不變

保留不變

SPI不變 (DEF)

認(rèn)證數(shù)據(jù)隨機(jī)

壓縮后只剩16個(gè)字節(jié)的認(rèn)證數(shù)據(jù)。

6.8.封裝安全凈載荷首部(ESP)

　　在隧道方式中,用ESP首部加密整個(gè)IP包,在隧道的入口點(diǎn)加密包以前,可以壓縮包的首部。當(dāng)包來(lái)自鏈路層時(shí),一定可以把IP包和它的長(zhǎng)度送入壓縮器。當(dāng)包在隨道中能重新排序時(shí),一定要用重新排序機(jī)理。

SPI不變

Opaque變換數(shù)據(jù)隨機(jī)

能加密而不能壓縮SPI后面的數(shù)據(jù)。

6.9.UDP首部

在[RFC-768]中說明了UDP首部。在子首部前面的IPV6的下一首部是DEF。

源口 不變(DEF)

目的口不變(DEF)

長(zhǎng)度推測(cè)

校驗(yàn)和隨機(jī),除非它是0時(shí)不變。

　　UDP首部的長(zhǎng)度字段一定與前面子首部的長(zhǎng)度字段相匹配,即,IP長(zhǎng)度包含的UDP凈載荷后面沒有任何填充。UDP首部典型的壓縮到2個(gè)字節(jié),UDP校驗(yàn)和。當(dāng)UDP的校驗(yàn)和是0時(shí),定義為不變,這樣又節(jié)約2個(gè)字節(jié)。

6.10.TCP首部

　　TCP首部在[RFC-793]中描述。在子首部前面的下一首部字段是DEF。有兩種壓縮TCP首部的方法。

6.10.1.有微分編碼的壓縮

源口不變(DEF)

目的口不變(DEF)

順序號(hào)DELTA

確認(rèn)號(hào)DELTA

偏移量不變

保留DELTA(如果上下關(guān)系不同,在標(biāo)志字節(jié)R標(biāo)志置1并發(fā)送絕對(duì)值)

Urg,Psh 隨機(jī)(放在標(biāo)志字節(jié))

Ack推測(cè)到1

Rst,Syn,Fin 推測(cè)到0

WindowDELTA(如果窗口改變,在標(biāo)志字節(jié)W置1并發(fā)送差值)

校驗(yàn)和隨機(jī)

緊急指針DELTA(如果緊急指針置1,發(fā)送絕對(duì)值)

選項(xiàng),填充DELTA(如果改變選項(xiàng),O標(biāo)志置1并發(fā)送全部選項(xiàng)和填充)

　　有TCP首部壓縮的包必須指出壓縮TCP的類型。這個(gè)方法本質(zhì)上是文件中的微分編碼技術(shù),壓縮TCP首部字段的位置是不同的,用O標(biāo)志,R標(biāo)志,取消C標(biāo)志。當(dāng)使用時(shí)標(biāo)選項(xiàng)和選項(xiàng)字段隨每個(gè)首部改變時(shí),O標(biāo)志允許壓縮TCP首部。DELTA值(除保留字段,選項(xiàng)和填充外)用文件中的編碼。傳送帶R標(biāo)志的保留字段值不必在壓縮器或解壓器中更新上下關(guān)系。

6.10.2.無(wú)微分編碼

源口不變(DEF)

目的口不變(DEF)

其余全部隨機(jī)

　　有TCP首部壓縮的包必須指出壓縮TCP-NODELTA的類型。當(dāng)壓縮TCP首部時(shí)用相同的CID空間并作為上下關(guān)系必須保存首部。能夠發(fā)送這種類型的包代替全包作為響應(yīng)一個(gè)首部的請(qǐng)求,能夠用在重新排序包的鏈路上和當(dāng)壓縮首部不改變時(shí)能夠代替全包發(fā)送。當(dāng)首部丟失頻率高時(shí),綜合壓縮器只能轉(zhuǎn)向發(fā)送壓縮TCP-NODELTA首部。

6.11.最小封裝首部[RFC-2004]

協(xié)議不變

原始源地址出現(xiàn)(S)不變

保留不變

首部校驗(yàn)和推測(cè)(從其它值計(jì)算)

原始目的地址不變

原始源地址不變(只有S=1出現(xiàn))

移動(dòng)通信很可能使用這個(gè)首部。

7.TCP壓縮首部丟失率低

　　由于壓縮首部的每個(gè)包傳送的比特?cái)?shù)較少,對(duì)于有固定的比特差錯(cuò)率的鏈路,壓縮首部比未壓縮首部包的丟失率低。這對(duì)于有高比特差錯(cuò)率的無(wú)線鏈路是很有利的。然而,因?yàn)門CP首部壓縮用微分編碼,由于在壓縮器中上下關(guān)系沒有適當(dāng)增加,單個(gè)丟失TCP分段能破壞一個(gè)完整的TCP發(fā)送窗口。以后解壓的首部將不同于壓縮前的首部并由于校驗(yàn)和失敗,TCP接收器必須丟棄它。TCP在廣域網(wǎng)連接中的最后一跳是在中速有丟失的鏈路上,如,無(wú)線LAN,由于時(shí)延-帶寬的乘積相當(dāng)大和比特差錯(cuò)率相當(dāng)高,用傳統(tǒng)的首部壓縮性能較差。下面介紹兩種簡(jiǎn)單的快速修復(fù)上下關(guān)系的機(jī)理。用這些機(jī)理壓縮首部,將改善在有丟失及低比特差錯(cuò)率的鏈路上的通過量。

7.1.兩次算法

　　解壓器可以計(jì)算TCP校驗(yàn)和,確定是否能適當(dāng)更新上下關(guān)系。如果校驗(yàn)和失敗,假設(shè)有丟失的分段引起差錯(cuò),就不能適當(dāng)更新上下關(guān)系。假設(shè)丟失分段包含的DELTA與當(dāng)前值相同,當(dāng)前分段的DELTA再加到上下關(guān)系上,就能更新上下關(guān)系。壓縮和再計(jì)算TCP校驗(yàn)和,解壓器檢驗(yàn)是否修復(fù)成功或是否應(yīng)該再一次應(yīng)用DELTA。各種TCP的大量轉(zhuǎn)換器的追蹤分析表明,應(yīng)用當(dāng)前分段的DELTA一次或兩次,將修復(fù)在數(shù)據(jù)流中所有單次丟失的上下關(guān)系,在83%和99%之間。對(duì)于確認(rèn)流,由于TCP的延時(shí)確認(rèn)機(jī)理,成功率是小的。在確認(rèn)流中,兩次機(jī)理,修復(fù)丟失的上下關(guān)系為53%到99%。這個(gè)思想的綜合實(shí)現(xiàn)能確定是否TCP流的一個(gè)確認(rèn)或數(shù)據(jù)流并用觀察全首部及壓縮首部確定分段長(zhǎng)度。試驗(yàn)多個(gè)分段長(zhǎng)度小的DELTA將得到確認(rèn)流中較高的修復(fù)成功率。

7.2.首部請(qǐng)求

　　對(duì)于TCP的確認(rèn)流兩次算法成功率較低,解壓器調(diào)用另一個(gè)修復(fù)上下關(guān)系機(jī)理。當(dāng)有一個(gè)丟失后,解壓器修復(fù)上下關(guān)系失敗時(shí),解壓器可以選擇請(qǐng)求壓縮器發(fā)送全首部。解壓器能夠識(shí)別壓縮器和發(fā)送到鏈路上的包。在這樣的鏈路上,解壓器可以給壓縮器發(fā)送一個(gè)CONTEXT-STATE包,指出一個(gè)或多個(gè)上下關(guān)系無(wú)效。一個(gè)壓縮包有一個(gè)無(wú)效的上下關(guān)系,解壓器不應(yīng)該每次發(fā)送一個(gè)CONTEXT-STATE包,應(yīng)該限制CONTEXT-STATE包的發(fā)送率,避免反向信道的洪峰。一個(gè)CONTEXT-STATE包能夠指出幾個(gè)上下關(guān)系超期,這項(xiàng)技術(shù)應(yīng)該用于代替發(fā)送幾個(gè)獨(dú)立的包。下圖說明CONTEXT-STATE包的格式：第一個(gè)字節(jié)是類型碼,允許其他壓縮協(xié)議共享CONTEXT-STATE類型的包。當(dāng)對(duì)TCP首部使用請(qǐng)求該類碼時(shí),用數(shù)值3,包的其余部分是一個(gè)字節(jié)CID的計(jì)數(shù)器和CID序列。在CONTEXT-STATE包的接收方,壓縮器必須標(biāo)記CID無(wú)效,保證在那些包流中發(fā)送的下一個(gè)包是全首部或CONPRESSED-TCP-NODELTA包。首部請(qǐng)求是最優(yōu)化的,因此,一個(gè)CONTEXT-STATE包的丟失不影響TCP首部壓縮的正確操作。當(dāng)CONTEXT-STATE包丟失時(shí),最終將發(fā)送一個(gè)新的CONTEXT-STATE或TCP超時(shí)并重新發(fā)送。用首部請(qǐng)求的最大優(yōu)點(diǎn)是在丟失鏈路上往返一次后,能修復(fù)TCP確認(rèn)流。這將避免TCP超時(shí)和不必要的重傳。由于較小的包有較低的丟失率,在兩個(gè)丟失之間TCP窗口能夠增大,因此,將得到較高的通過量。

8.配置參數(shù)

　　首部壓縮參數(shù)是以規(guī)定的方法,在鏈路層實(shí)現(xiàn)時(shí)協(xié)商的。本首部壓縮方案的固定參數(shù)是：

MIN-WRAP--G值往返的最小時(shí)間,3秒。

下列參數(shù)能在壓縮器和解壓器之間協(xié)商。若不協(xié)商,就是規(guī)定的缺省值。

F-MAX-PERIOD--不發(fā)送全首部,可以發(fā)送壓縮非TCP首部的最大數(shù)。

范圍--1到65535。

缺省值--256。

F-MAX-TIME--在發(fā)送最后全首部后,可以發(fā)送不大于F-MAX-TIME秒的壓縮首部。

范圍--1到255秒。

缺省值--5秒。

注意：當(dāng)壓縮器丟失他的狀態(tài)時(shí),F-MAX-PERIOD和F-MAX-TIME應(yīng)該小些。

MAX-HEADER--可以壓縮的最大首部長(zhǎng)度,以字節(jié)為單位。

范圍--60到65535字節(jié)。

缺省值--168字節(jié),包括：2個(gè)IPV6基本首部,1個(gè)密鑰MD5認(rèn)證首部,1個(gè)

最大長(zhǎng)度的TCP首部。

TCP-SPACE--TCP的最大CID值。

范圍--3到255。

缺省值--15(給16個(gè)CID值)。

NO-TCP-SPACE--非TCP的最大CID值。

范圍--3到65535。

缺省值--15(給16個(gè)CID值)。

摘自《網(wǎng)絡(luò)通信世界》