基于6LOWPAN的IPv6傳感器網(wǎng)絡報頭壓縮方案的設計與實現(xiàn)
加入技術交流群
2．2 改進方案
雖然RFC4944中提到的壓縮方案已經(jīng)很精簡，但是這種方法仍然存有冗余。方案中對于IPv6報頭的跳數(shù)限制字段并沒有壓縮，而是始終占用1 B存放在未壓縮字段中。但是在實際中，1，64，255這三種跳數(shù)限制已經(jīng)可以滿足大部分的應用需求，因此本文提出一種支持對跳數(shù)限制壓縮的IPv6報頭壓縮方法，最理想情況下可以將IPv6報頭壓縮到1B。
如果將跳數(shù)限制壓縮，就要從HC1字節(jié)中節(jié)省出兩個比特，用來標識跳數(shù)限制的4種狀態(tài)(未壓縮、1、64、255)，HC1字節(jié)中前4個比特都用來描述IPv6源地址和目的地址的壓縮狀態(tài)，存在一定的冗余性。因為根據(jù)上文的分析，不需要1個比特來專門標識IPv6接口標識符的壓縮狀態(tài)，如果IEEE 802．15．4尋址模式為64位擴展地址，接口標識符可以直接壓縮掉，如果尋址模式為16位短地址，接口標識符不可以壓縮，需要攜帶在未壓縮字段中。因此HC1字節(jié)中只需要2個比特標識IPv6地址前綴的壓縮狀態(tài)，可以節(jié)省下2個比特用來標識跳數(shù)限制的壓縮狀態(tài)。具體壓縮方案如圖4所示。本文引用地址：http://cafeforensic.com/article/161471.htm
2．3 實現(xiàn)流程
為了實現(xiàn)IPv6報頭壓縮與解壓縮的功能，在適配層和網(wǎng)絡層之間加入壓縮控制層，網(wǎng)絡層的數(shù)據(jù)經(jīng)過壓縮控制層的處理之后交給適配層處理，同樣適配層的數(shù)據(jù)經(jīng)過壓縮控制層之后交給網(wǎng)絡層處理，處理流程如圖5所示。系統(tǒng)頭文件中定義一個預編譯開關來控制IPv6報頭是否要進行壓縮，當開關打開時，數(shù)據(jù)包將會進入壓縮器進行處理。壓縮器首先要完成節(jié)點本地環(huán)境的檢測，主要包括對IEEE 802．15．4地址模式、IPv6地址前綴類型、服務類型和流標簽狀態(tài)、下一個首部類型、跳數(shù)限制需求和下一個首部壓縮狀態(tài)的檢測，之后根據(jù)節(jié)點本地環(huán)境進行HC1字節(jié)和未壓縮字段的填充。
數(shù)據(jù)包的解壓縮過程正好是數(shù)據(jù)包壓縮的逆程，解壓縮器首先要根據(jù)IEEE 802．15．4地址類型還原接口標識符，然后通過解碼HC1字節(jié)可以將IPv6報頭中壓縮掉的字段恢復出來，最后在配合未壓縮字段的內(nèi)容就可以還原完整的IPv6報頭。
評論