capwap學習筆記——初識capwap（四）

標籤：http   使用   width   檔案   資料   類   

2.5.7 CAPWAP傳輸機制

WTP和AC之間使用標準的UDP用戶端/伺服器模式來建立通訊。

CAPWAP協議支援UDP和UDP-Lite [RFC3828]。

￠ 在IPv4上，CAPWAP控制和資料通道使用UDP。此時CAPWAP報文中的UDP校正和必須設定為0。AC上的CAPWAP控制報文連接埠為UDP眾所周知連接埠5246，資料報文連接埠為UDP眾所周知連接埠5247 ，WTP可以隨意選擇CAPWAP控制和資料連接埠。

￠ 在IPv6上，CAPWAP控制通道一般使用UDP，而資料通道可以使用UDP或者UDP-Lite。UDP-Lite為預設的資料通道傳輸協議。當使用UDP-Lite協議的時候，校正和必須為8. UDP-Lite使用的連接埠與UDP一致。

2.5.8 分區、重組、MTU發現

CAPWAP協議在應用程式層上提供IP報文的分配和重組服務，由於使用隧道機制，報文分區中間的傳輸媒介來說是透明的。因此可以在任何網路架構（防火牆，NAT等）上使用CAPWAP協議。

CAPWAP實現的分區機制也有局限和不足，協議RFC4963中詳細描述。

CAPWAP執行MTU發現來避免分區。

一旦WTP發現AC，且想要與這個AC建立一個CAPWAP會話，它必須執行一個Path MTU (PMTU)發現。IPv4的PMTU發現過程在RFC1191中詳細描述。IPv6使用RFC4821。

2.5.9 報文格式

CAPWAP協議可靠機制要求訊息必須成對，由請求和回應群組成。所有的請求訊息的訊息類型值都為奇數，所有的響應訊息類型值都為偶數。

如果WTP或者AC接收到了一個不認識的訊息，訊息類型是奇數，那麼會將訊息類型值加一，然後響應給寄件者，並且在響應中帶有“不認識的訊息類型”元素。如果不認識的訊息類型為偶數，那麼這個訊息將會被忽略。

2.5.9.1 UDP-Lite協議的簡單介紹

UDP-Lite協議更加適應於網路的差錯率比較大，但是應用對輕微差錯不敏感的情況，例如即時視頻的播放等。

那麼它與傳統的UDP協議有什麼不同呢？

傳統的UDP協議是對其載荷（Payload）進行完整的校正的，如果其中的一些位（哪怕只有一位）發生了變化，那麼整個資料包都有可能被丟棄，在某些情況下，丟掉這個包的代價是非常大的，尤其當包比較大的時候。

在UDP-Lite協議中，一個資料包到底需不需要對其載荷進行校正，或者是校正多少位都是由使用者控制的，並且UDP-Lite協議就是用UDP協議的Length欄位來表示其Checksum Coverage的，所以當UDP-Lite協議的Checksum Coverage欄位等於整個UDP資料包（包括UDP頭和載荷）的長度時，UDP-Lite產生的包也將和傳統的UDP包一模一樣。事實上，Linux對UDP-Lite協議的支援也是通過在原來的UDP協議的基礎上添加了一個setsockopt選項來實現控制發送和接受的checksum coverage的。

2.5.9.2 CAPWAP報文的簡單介紹

CAPWAP控制協議包括兩個永遠不會被DTLS保護的訊息：Discovery Request和Discovery Response。

報文格式如下：

其餘的CAPWAP控制協議報文必須被DTLS協議加密，因此包括一個CAPWAP DTLS Header。

CAPWAP協議對資料報文的DTLS加密是可選的。

CAPWAP頭部格式：

￠ UDP頭：所有的CAPWAP報文都被封裝在UDP或者UDP-Lite（ipv6）中。

￠ CAPWAP DTLS頭：所有的被DTLS加密的CAPWAP報文都有該頭部首碼。

￠ DTLS頭：DTLS頭部為CAPWAP的載荷提供認證和Data Encryption Service。DTLS在RFC4347中定義。

￠ CAPWAP頭：所有的CAPWAP協議報文都用同一個頭部，該頭部位於CAPWAP預判碼或者DTLS頭之後。

￠ 無線載荷：包含無線載荷的CAPWAP協議報文稱為CAPWAP資料報文。CAPWAP協議並沒有對無線載荷的格式做強制要求，而是由無線協議標準決定。

￠ 控制頭：CAPWAP協議包含一個訊號元件，稱為CAPWAP控制協議。所有的CAPWAP控制報文都包含一個控制頭，CAPWAP資料報文則不包含該頭部。

￠ 訊息元素：CAPWAP控制報文包含一個或者多個訊息元素，這些跟在元素在控制頭之後。這些訊息元素以TLV格式出現（類型/長度/值）

2.5.9.2.1 預判碼

2 種 CAPWAP 首部的前 8 位為預判碼，用於快速判斷此報文是否經過 DTLS 加密。前 4 位指明 CAPWAP 版本，目前的版本號碼為 0；後 4 位值為 1 時是 CAPWAP DTLS 首部，值為 0 時是 CAPWAP 首部。

0

0 1 2 3 4 5 6 7

+-+-+-+-+-+-+-+-+

|Version| Type |

2.5.9.2.2 CAPWAP DTLS 首部

標識此報文經過 DTLS 加密。長度為 32 位，包括 8 位預判碼和 24 位預留碼。

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|CAPWAP Preamble| Reserved |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.5.9.2.3 CAPWAP 首部

CAPWAP 協議的所有報文都包含 CAPWAP 首部，在控制通道收到則是控制報文，在資料通道收到則是資料報文，

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|CAPWAP Preamble| HLEN | RID | WBID |T|F|L|W|M|K|Flags|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Fragment ID | Frag Offset |Rsvd |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| (optional) Radio MAC Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| (optional) Wireless Specific Information |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Payload .... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

報文各部分組成如下：

(1)CAPWAP Preamble：8 位預判碼。

(2)HLEN：5 位首部長度，指明 CAPWAP 首部的長度。

(3)RID：5 位無線頻率識別 (RFID)符，指明此報文的來源射頻。

(4)WBID：5 位無線幀標識符， 指明無線框架類型， 有 IEEE802.11, IEEE802.16 和 EPCGlobal 3 種。

(5)T：1 位元據幀標識符，值為 1 時資料幀是由 WBID指明的類型，值為 0 時是 IEEE802.3 資料幀。

(6)F：1 位分組標誌，值為 1 時此報文是一個 CAPWAP報文分組，需要和其他分組重組成完成的報文。

(7)L：1 位分組結束標誌，值為 1 時此報文是最後一個分組。

(8)W：1 位選項標誌，值為 1 時存在 Wireless Specific Information 選項。

(9)M：1 位選項標誌，值為 1 時存在 Radio MAC Address選項。

(10)K：1 位存活標誌，指明此報文用於保持串連存活，不能攜帶使用者資料。

(11)Flags：3 位預留標誌。

(12)Fragment ID：16 位分組標識符，識別不同的報文分組，ID 相同的分組屬於同一個 CAPWAP 報文。

(13)Fragment Offset：13 位分組位移，各分組在該CAPWAP 報文中的位置。

(14)Reserved：3 位預留碼。

(15)Radio MAC Address：32 位射頻 MAC 位址，不足32 位以全 0 填充。指明報文來源射頻的 MAC 位址。

(16)Wireless Specific Information：32 位特殊無線資訊，不足 32 位以全 0 填充。包含特殊資訊，如與 IEEE 802.11, IEEE802.16 和 EPCGlobal 的關聯等。

(17)Payload：資料報文是使用者資料，控制報文則是控制訊息，詳細的控制訊息定義參見文獻[1]。

2.5.9.3CAPWAP資料報文

CAPWAP資料報文有兩種類型：CAPWAP Data channel Keep-Alive 報文和Data Payload報文。CAPWAP Data hannel Keep-Alive報文用於同步控制和資料通道，鑑效組資料通道的串連。Data Payload報文用於在AC和WTP之間傳輸使用者資料。

2.5.9.3.1 CAPWAP Data Channel Keep-Alive

該報文的目的在於保持通道的可用性。當DataChannelKeepAlive定時器到期，WTP發送該報文，同時設定DataChannelDeadInterval定時器。

在報文中，除了HELN欄位和K標誌位，其餘欄位和標誌位均被置為0。當收到KEEPALIVE報文，AC將回應一個KEEPALIVE報文給WTP。

WTP在收到AC回應的KEEPALIVE報文後，取消DataChannelDeadInterval定時器並且重設DataChannelKeepAlive定時器。然後WTP將KEEPALIVE報文當做控制訊息進行重發。如果在DataChannelDeadInterval定時器到期時仍然沒有收到AC的回應報文，WTP將刪除DTLS的控制SESSION，如果存在資料SESSION也同時刪除。

KEEPALIVE報文格式如下所示：

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Message Element Length | Message Element [0..N] ...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

報文被封裝在CAPWAP報文的payload欄位中。

Message Element Length: 16bit的長度欄位，最大為65535。

Message Element[0..N]: 攜帶的KEPPALIVE報文資料，SEESION ID是必須攜帶的。

2.5.9.3.2 Data Payload

CAPWAP Data Payload報文封裝了需要轉寄的使用者資料，裡面可能是802.3幀也有可能是無線資料幀，參見3.2章節。

2.5.9.3.3 DTLS資料通道的建立

如果AC和WTP被配置為DTLS隧道傳輸模式，那麼就必須初始化DTLS SESSION。為了避免重新評鑑、認證AC和WTP，DTLS資料通道應該利用TLS SESSION的特徵。

AC DTLS實現不應該在沒有控制通道的情況下初始化資料通道SESSION。

2.5.9.4 CAPWAP控制報文

CAPWAP控制報文分為以下幾種類型：

Discovery：發現網路中的AC，AC位置和能力

Join：WTP用於向AC請求服務，AC用於響應WTP

Control Channel Management：維持控制通道

WTP Configuration Management：AC給WTP發送設定檔。

Station Session Management：AC發送station策略給WTP

Device Management Operations:請求和發送firmware給WTP

Binding-Specific CAPWAP Management Messages: AC和WTP用於交換協議指定的CAPWAP管理資訊。可能交換一個station的串連狀態資訊。

2.5.9.3.1 CAPWAP Discovery Operations

￠ Discovery Request Message

WTP用Discovery Request來自動探索網路中可用的AC，提供自己的基本效能給AC。

￠ Discovery Response Message

AC使用Discovery Response，將自己支援的服務告訴給請求服務的WTP。

￠ Primary Discovery Request Message

WTP發送Primary Discovery Request用於：判斷它首選（或者配置的）的AC是否可用或者執行一個Path MTU Discovery

￠ Primary Discovery Response

AC使用Primary Discovery Response告訴WTP自己當前可用，與支援服務。

當WTP被配置了一個首選的AC，但是現在卻串連在另外一個AC上，此時會發送Primary Discovery Request。因為WTP只有一個CAPWAP狀態機器，WTP在run狀態發送Primary Discovery Request，AC不傳輸這個訊息

2.5.9.3.2 CAPWAP Join Operations

￠ Join Request

在與AC建立DTLS串連之後，WTP使用Join Request來向一個AC請求服務

￠ Join Response

AC使用Join Response告知WTP是否會向其提供服務

2.5.9.3.3 Control Channel Management

￠ Echo Request

￠ Echo Response

Echo Request和Echo Response用於在控制報文沒有發送的時候，來顯式的維持控制通道的串連

2.5.9.3.4 WTP Configuration Management

￠ Configuration Status Request

WTP用於發送自己當前的配置給AC

￠ Configuration Status Response

AC提供自己的配置資料給WTP，覆蓋WTP所請求的配置

￠ Configuration Update Request

run狀態的時候，AC發送給WTP用於修改WTP上的配置。

￠ Configuration Update Response

響應Configuration Update Request

￠ Change State Event Request

1：當WTP收到來自AC的Configuration Status Response，WTP使用Change State Event Request來提供WTP radio的目前狀態，確認AC提供的配置已經成功應用

2：在run狀態下，WTP發送Change State Event Request來告訴AC，WTP radio發生了意料之外的改變。

￠ Change State Event Response：

響應Change State Event Request

￠ Clear Configuration Request：

AC用於請求WTP將自己的配置恢複至出廠預設值

￠ Clear Configuration Response

WTP恢複出廠預設值後，發送給AC的確認。

CAPWAP協議提供彈性的WTP組態管理機制,有兩種方法：

1：WTP沒有任何配置，接受AC提供的任何配置

2：WTP儲存AC提供的靜態記憶體中的不是預設值的配置資料，然後重啟初始化配置。

2.5.9.3.5 Device Management Operations（可選）

￠ Image Data Request

在WTP和AC之間交換，用於WTP下載一個新的firmware

￠ Image Data Response

響應Image Data Response

￠ Reset Request

要求WTP進行重啟。

￠ Reset Response

響應Reset Request

￠ WTP Event Request

WTP用來發送資訊給AC。WTP Event Request可能是階段性發送，或者是作為一個WTP同步事件的響應。

￠ WTP Event Response

響應WTP Event Request

￠ Data Transfer Request

將WTP上的調試資訊發送給AC

￠ Data Transfer Response

響應 Data Transfer Request

WTP Event Request是WTP發送一些定義好的狀態資訊，如Decryption Error Report，Duplicate IPv4 Address等等，也能用於發送Vendor Specific Payload

Data Transfer Request可以由AC發送，也可以由WTP發送。

2.5.9.3.6 CAPWAP定義的firmware下載過程:

firmware的下載可以發生在image data狀態或者run狀態。CAPWAP協議並沒有提供讓AC來識別是否WTP提供的firmware資訊是否正確，或者WTP是否正確儲存了firmware。

2.5.9.3.7 Station Session Management

￠ Station Configuration Request

AC用於建立，修改，刪除WTP上的staion 工作階段狀態

￠ Station Configuration Response

響應Station Configuration Request