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

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的載荷提供認證和加密服務。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 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 位射頻辨別符，指明此封包的來源射頻。

(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

——————————————————