1. 首頁 > 云知道 > >

GRE的Key和Sequence Number擴展( 二 )

云知道


序列號的取值范圍從0到（2**32）-1 。第一個數據報發送時序列號為0 。這樣序列號就是一個自由運行的由模2**32表示的計數器 。接收方保留上一次成功拆封的報文的序列號值 。在建立GRE隧道時,這個值應該設為(2**32)-1 。
當拆封者接收到一個無效序列號的數據報文時 ， 它應該靜靜的丟棄該數據報文 。當收到的數據報文的序列號小于或等于上一次成功拆封的數據報文的序列號時 ， 收到的報文被視為序列號無效 。收到消息的序列號的值假如處于上一次成功收到的序列號和該序列號的前2**31-1個值之間時（包括這兩個值） ， 它被認為是小于或者等于上一次成功收到的序列號 。
假如接收到的數據報文序列號有效 ， 它被成功拆封 。序列號有效的數據報文是序列號比上一個成功拆封數據報文的序列號正好大1（模2**32）,或者sequencenumber域不出現的數據報文(S位沒有置位) 。
假如接收到的數據報文既不是有效序列號的數據報 ， 也不是無效序列號的數據報 ， 表明出現了一個序列號缺口（sequencenumbergap） 。接收者可以試圖執行較小的緩沖來恢復已發送數據報文的最初的順序 。在這種情況下,數據報文可以放在以序列號排序的緩沖區中 。假如收到一個有效序列號的數據報文并被成功拆封 。接收者應該查詢緩沖區的頭部來判定是否下一個有效序列號的數據報文已經到達 。假如是,接收者應該同緩沖區中可能出現的其他緊接著的有效序列號報文一樣進行拆封 ?！吧弦粋€成功拆封的序列號”應該隨后被置為最后一個從緩沖區中拆封的數據報的序列號 。
在任何情況下 ， 緩沖區中的任何一個數據報都不會等待超過OUTOFORDER_TIMER微秒 。假如一個數據報文已經等待了那么長時間,接收者必須立即按所排的順序遍歷緩沖區 ， 拆封報文(忽略任意序列號缺口)直到緩沖區中沒有等待超過OUTOFORDER_TIMER微秒的數據報文 ?！吧弦粋€成功拆封的序列號”應該隨后被置為最后一個從緩沖區中拆封的數據報的序列號 。
接收者可以對每一個業務流（擁有同一個Key值的數據報文屬于同一個業務流）的緩沖報文的數量加以限制 ， 假如可導致接收者在一個給定緩沖區中放置多于MAX_PERFLOW_BUFFER個數據報文,那么緩沖區頭的數據報文立即被拆封 ， 而不管起序列號 ， “上一個成功拆封的序列號”置為其序列號 。然后把新到達的數據報文放到緩沖區中 。
注重序列號用來檢測丟失的數據報文與/或恢復在傳輸中可能已經失序的數據報文的最初順序（使用緩沖） 。應該適當地使用序列號選項；非凡地,當隧道協議的高層協議包括有效序列號傳輸機制或者可忍受失序傳輸時 ， 避免使用序列號選項將不失為一個好主意 。僅在特定情況下GRE隧道攜帶的協議要求有序交付時,僅相應的封裝在GRE中數據報文可以在發送時設置sequence比特位 。
失序數據報文的重新排序可以由拆封者執行 ， 以提高性能以及對網絡重新排序的容錯性 。當高層協議使用了含狀態壓縮或加密時 ， 提供一個小的重排序緩沖區(MAX_PERFLOW_BUFFER)將有助于提高性能 。因為含狀態壓縮或加密的狀態因為報文的丟失而重置 ， 緩沖將有助于提高網絡對少數報文的重排序的容忍性 。
3.安全方面的考慮
本文檔描述了GRE頭部（參考文獻[1]）可能攜帶的兩個擴展域即Key和SequenceNumber 。當使用Sequencenumber域時,通過給報文填入一個隨意的序列號從而發起一個拒絕服務攻擊（DenialofService）是可能的 。為了防止受此類攻擊,必須使用IP安全協議（參考文獻[4]）來保護GRE頭部以及隧道的凈載 。ESP(封裝安全凈載 ， EncapsulatingSecurityPayload ， 參考文獻[5])或者AH(認證頭 ， 參考文獻[6])必須用來保護GRE頭部 。假如使用ESP ， 它保護IP凈載包括GRE 。假如使用AH,對整個數據報文而不是某些域進行認證 。注重在排序或安全方面都不涉及(不管它的名字的意義) 。

推薦閱讀