RFC5415(中文)無(wú)線AP控制和配置CAPWAP協(xié)議標(biāo)準(zhǔn)-添加書(shū)簽版

1、本文翻譯者：weicq2000(，2013 年 7 月 4 日譯)network working groupp. calhoun, ed.request for comments: 5415cisco systems, inc.category: standards trackm. montemurro, ed.research in motiond. stanley, ed.aruba networksmarch 2009無(wú)線 ap 控制和配置(capwap)協(xié)議標(biāo)準(zhǔn)本備忘錄狀態(tài)本文檔規(guī)定互聯(lián)網(wǎng)通信的互聯(lián)網(wǎng)標(biāo)準(zhǔn)跟蹤協(xié)議，并請(qǐng)求討論和提出改進(jìn)建議。本協(xié)議的標(biāo)準(zhǔn)

2、化程度和狀態(tài)，參閱“internet official protocol standards”(std 1)的目前版本。分發(fā)本備忘錄不受限制。版權(quán)聲明版權(quán)所有(c)2009 ietf trust 和本文檔撰寫(xiě)者(們)。保留所有權(quán)利。本文檔遵從本文檔頒布日有效的 bcp 78 和 ietf trust 的 legal provisions relating toietf documents (/license-info)規(guī)定。請(qǐng)仔細(xì)查閱這些文檔，因?yàn)檫@些文檔解釋了對(duì)于本文檔來(lái)說(shuō)，您享有的權(quán)利和受到的限制。本文檔可能包括在 2008 年 11 月 10

3、日之前出版的或可公開(kāi)獲得的、來(lái)自 ietf documents或 ietf contributions 的材料。材料的某些部分的版權(quán)控制人(們)可能沒(méi)有授權(quán) ietf trust可在 ietf standards process 以外修改該材料。沒(méi)有獲得這些材料的版權(quán)控制人(們)的適當(dāng)許可，在 ietf standards process 以外可能不能修改本文檔，在 ietf standards process 以外可能不能創(chuàng)建本文檔的衍生作品，但是可以將本文檔作為 rfc 出版或?qū)⑵浞g為英文以外的語(yǔ)言。摘要本規(guī)范定義無(wú)線 ap 控制和配置(control and provisioning

4、of wireless access points, capwap)協(xié)議，滿(mǎn)足在 rfc4564 中由 capwap working group 定義的目標(biāo)。capwap 協(xié)議在設(shè)計(jì)上頗具靈活性，這使其能夠用于各種無(wú)線技術(shù)。本文檔介紹基礎(chǔ) capwap 協(xié)議，而獨(dú)立的綁定擴(kuò)展使其可與其他無(wú)線技術(shù)一起使用。目錄第1章序言1-1目標(biāo)1-2本文檔中的約定1-3特約作者1-4術(shù)語(yǔ)第2章協(xié)議綜述2-1無(wú)線綁定定義2-2capwap會(huì)話(huà)建立綜述2-3capwap狀態(tài)機(jī)定義2-3-1capwap協(xié)議狀態(tài)轉(zhuǎn)換2-3-2capwap/dtls接口2-4在capwap協(xié)議中使用dtls2-4-1dtls握手處理流

5、程2-4-2dtls會(huì)話(huà)建立2-4-3dtls錯(cuò)誤處理2-4-4dtls端點(diǎn)認(rèn)證和授權(quán)第3章capwap傳送3-1udp傳送3-2udp-lite傳送3-3ac發(fā)現(xiàn)3-4分段/重組3-5mtu發(fā)現(xiàn)第4章capwap分組格式4-1capwap前導(dǎo)4-2capwap dtls首部4-3capwap首部4-4capwap數(shù)據(jù)消息4-4-1capwap數(shù)據(jù)通道保持激活4-4-2數(shù)據(jù)凈荷4-4-3建立dtls數(shù)據(jù)通道4-5capwap控制消息4-5-1控制消息格式4-5-2服務(wù)質(zhì)量4-5-3重傳4-6capwap協(xié)議消息要素4-6-1ac 描述符4-6-2ac ipv4列表4-6-3ac ipv6列表4

6、-6-4ac名稱(chēng)4-6-5帶優(yōu)先權(quán)的ac名稱(chēng)4-6-6ac時(shí)間戳4-6-7添加mac acl條目4-6-8添加站4-6-9capwap控制ipv4地址4-6-10capwap控制ipv6地址4-6-11capwap本地ipv4地址4-6-12capwap本地ipv6地址4-6-13capwap計(jì)時(shí)器4-6-14capwap傳輸協(xié)議4-6-15數(shù)據(jù)傳輸數(shù)據(jù)4-6-16數(shù)據(jù)傳輸模式4-6-17解密錯(cuò)誤報(bào)告4-6-18解密錯(cuò)誤報(bào)告周期4-6-19刪除mac acl條目4-6-20刪除站4-6-21發(fā)現(xiàn)類(lèi)型4-6-22重復(fù)的ipv4地址4-6-23重復(fù)的ipv6地址4-6-24空閑超時(shí)4-6-25ec

7、n支持4-6-26映像數(shù)據(jù)4-6-27映像標(biāo)識(shí)符4-6-28映像信息4-6-29啟動(dòng)下載4-6-30位置數(shù)據(jù)4-6-31最大消息長(zhǎng)度4-6-32mtu發(fā)現(xiàn)填充4-6-33無(wú)線電設(shè)備管理狀態(tài)4-6-34無(wú)線電設(shè)備運(yùn)行狀態(tài)4-6-35結(jié)果代碼4-6-36返回的消息要素4-6-37會(huì)話(huà)id4-6-38統(tǒng)計(jì)量計(jì)時(shí)器4-6-39特定供應(yīng)商凈荷4-6-40wtp 主板(board)數(shù)據(jù)4-6-41wtp描述符4-6-42wtp回退4-6-43wtp幀隧道模式4-6-44wtp mac類(lèi)型4-6-45wtp名稱(chēng)4-6-46wtp無(wú)線電設(shè)備統(tǒng)計(jì)量4-6-47wtp重啟統(tǒng)計(jì)量4-6-48wtp靜態(tài)ip地址信息4

8、-7capwap 協(xié)議計(jì)時(shí)器4-7-1changestatependingtimer4-7-2datachannelkeepalive4-7-3datachanneldeadinterval4-7-4datachecktimer4-7-5discoveryinterval4-7-6dtlssessiondelete4-7-7echointerval4-7-8idletimeout4-7-9imagedatastarttimer4-7-10maxdiscoveryinterval4-7-11reportinterval4-7-12retransmitinterval4-7-13silentint

9、erval4-7-14statisticstimer4-7-15waitdtls4-7-16waitjoin4-8capwap協(xié)議變量4-8-1adminstate4-8-2discoverycount4-8-3faileddtlsauthfailcount4-8-4faileddtlssessioncount4-8-5maxdiscoveries4-8-6maxfaileddtlssessionretry4-8-7maxretransmit4-8-8retransmitcount4-8-9wtpfallback4-9wtp保存的變量4-9-1adminrebootcount4-9-2fram

10、eencaptype4-9-3lastrebootreason4-9-4mactype4-9-5preferredacs4-9-6rebootcount4-9-7static ip address4-9-8wtplinkfailurecount4-9-9wtplocation4-9-1 . wtpname第5章capwap發(fā)現(xiàn)操作5-1發(fā)現(xiàn)請(qǐng)求消息5-2發(fā)現(xiàn)響應(yīng)消息5-3主發(fā)現(xiàn)請(qǐng)求消息5-4主發(fā)現(xiàn)響應(yīng)消息第6章capwap加入操作6-1加入請(qǐng)求6-2加入響應(yīng)第7章控制通道管理7-1回顯請(qǐng)求7-2回顯響應(yīng)第8章wtp配置管理8-1配置一致性8-1-1 配置靈活性8-2配置狀態(tài)請(qǐng)求8-3配置狀態(tài)響

11、應(yīng)8-4配置更新請(qǐng)求8-5配置更新響應(yīng)8-6改變狀態(tài)事件請(qǐng)求8-7改變狀態(tài)事件響應(yīng)8-8清除配置請(qǐng)求8-9清除配置響應(yīng)第9章設(shè)備管理操作9-1固件管理9-1-1映像數(shù)據(jù)請(qǐng)求9-1-2映像數(shù)據(jù)響應(yīng)9-2復(fù)位請(qǐng)求9-3復(fù)位響應(yīng)9-4wtp事件請(qǐng)求9-5wtp事件響應(yīng)9-6數(shù)據(jù)傳送9-6-1數(shù)據(jù)傳送請(qǐng)求9-6-2數(shù)據(jù)傳送響應(yīng)第10章站點(diǎn)會(huì)話(huà)管理10-1站點(diǎn)配置請(qǐng)求10-2站點(diǎn)配置響應(yīng)第11章nat考慮第12章安全考慮12-1capwap安全12-1-1轉(zhuǎn)換受保護(hù)數(shù)據(jù)為不受保護(hù)數(shù)據(jù)12-1-2轉(zhuǎn)換不受保護(hù)數(shù)據(jù)為受保護(hù)數(shù)據(jù)(插入)12-1-3刪除受保護(hù)記錄12-1-4插入不受保護(hù)記錄12-1-5應(yīng)用md

12、512-1-6capwap分段12-2會(huì)話(huà)id安全12-3發(fā)現(xiàn)或dtls設(shè)置攻擊12-4伴隨dtls會(huì)話(huà)的干擾12-5capwap預(yù)配置12-6在capwap中使用預(yù)共享密鑰12-7在capwap中使用證書(shū)12-8在cn字段中使用mac地址12-9aaa安全12-10wtp固件第13章運(yùn)行考慮第14章傳輸考慮第15章iana考慮15-1ipv4 多播地址15-2ipv6多播地址15-3udp端口15-4capwap消息類(lèi)型15-5capwap首部標(biāo)記15-6capwap控制消息標(biāo)記15-7capwap消息要素類(lèi)型15-8capwap無(wú)線綁定標(biāo)識(shí)符15-9ac安全類(lèi)型15-10ac dtls策略

13、15-11ac信息類(lèi)型15-12capwap傳輸協(xié)議類(lèi)型15-13數(shù)據(jù)傳送類(lèi)型15-14數(shù)據(jù)傳送模式15-15發(fā)現(xiàn)類(lèi)型15-16 ecn支持15-17無(wú)線電設(shè)備管理狀態(tài)15-18無(wú)線電設(shè)備運(yùn)行狀態(tài)15-19無(wú)線電設(shè)備故障原因15-20結(jié)果代碼15-21返回的消息要素原因15-22wtp主板數(shù)據(jù)類(lèi)型15-23wtp描述符類(lèi)型15-24wtp回退模式15-25wtp幀隧道模式15-26wtp mac類(lèi)型15-27 wtp無(wú)線電設(shè)備統(tǒng)計(jì)量故障類(lèi)型15-28wtp重啟統(tǒng)計(jì)量故障類(lèi)型第16章致謝第17章參考文獻(xiàn)17-1標(biāo)準(zhǔn)類(lèi)參考文獻(xiàn)17-2信息類(lèi)參考文獻(xiàn)編輯通訊錄第 1 章序言這個(gè)文檔介紹 capwap

14、 協(xié)議，一個(gè)標(biāo)準(zhǔn)的、互操作協(xié)議，它使接入控制器(accesscontroller, ac)能夠管理無(wú)線終端點(diǎn)(wireless termination points, wtps)的集合。capwap 協(xié)議的定義與層 2(l2)技術(shù)無(wú)關(guān)，滿(mǎn)足在“無(wú)線接入點(diǎn)的控制和配置目標(biāo)(objectives for controland provisioning of wireless access points (capwap)”rfc4564中的目標(biāo)。集中式 ieee 802.11 無(wú)線局域網(wǎng)(wireless local area network, wlan)架構(gòu)的出現(xiàn)，該架構(gòu)中 ieee 802.11

15、 wtps 由 ac 輕松管理，暗示基于標(biāo)準(zhǔn)的、可互操作的協(xié)議能夠極大簡(jiǎn)化無(wú)線網(wǎng)絡(luò)部署和管理。wtps 需要一系列動(dòng)態(tài)管理和控制功能，這些功能與 wtps 連接無(wú)線和有線媒介的主要任務(wù)有關(guān)。管理 wtps 的傳統(tǒng)協(xié)議或者是通過(guò) http、通過(guò)特定第 2 層專(zhuān)有方法人工靜態(tài)配置，或者就根本沒(méi)有(如果 wtps 是自組織的)。在rfc5416中定義的 ieee 802.11 綁定，用于支持 capwap 協(xié)議與 ieee 802.11 wlan 網(wǎng)絡(luò)一起應(yīng)用。capwap 假設(shè)，網(wǎng)絡(luò)被配置成由通過(guò) ip(internet protocol)與 ac 通信的多個(gè) wtps 構(gòu)成。 wtps 被看作是

16、由 ac 控制的遠(yuǎn)端無(wú)線電設(shè)備射頻(radio frequency, rf)接口。capwap 協(xié)議支持兩種運(yùn)行模式：split mac(medium access control)和 local mac。在 split mac 運(yùn)行模式，所有第 2 層無(wú)線數(shù)據(jù)和管理幀由 capwap 協(xié)議封裝，并在 ac 和 wtp 間交換。如圖 1 所示，從移動(dòng)設(shè)備(本規(guī)范將移動(dòng)設(shè)備稱(chēng)為站(station, sta)收到的無(wú)線幀，直接由 wtp 封裝并轉(zhuǎn)發(fā)到 ac。無(wú)線幀無(wú)線phy/maccapwap子層stawtpac圖 1典型 split mac capwap 架構(gòu)local mac 運(yùn)行模式可用于本

17、地橋接的數(shù)據(jù)幀，或用于隧道化為 802.3 幀的數(shù)據(jù)幀。后者暗示 wtp 執(zhí)行 802.11 integration 功能。在每一種情況，第 2 層無(wú)線管理幀由 wtp 在本地處理，接著轉(zhuǎn)發(fā)到 ac。圖 2 顯示 local mac 模式，在該模式中，站發(fā)射無(wú)線幀，該無(wú)線幀用 802.3 幀封裝，并被轉(zhuǎn)發(fā)到 ac。無(wú)線幀802.3幀無(wú)線phy/maccapwap子層stawtpac圖 2典型 local mac capwap 架構(gòu)提供具有安全證書(shū)的 wtps 和決定授權(quán)哪個(gè) wtps 提供業(yè)務(wù)，傳統(tǒng)通過(guò)專(zhuān)用解決方案處理。允許以可互操作的方式、從集中的 ac 執(zhí)行這些功能增加了可管理性，使網(wǎng)絡(luò)運(yùn)

18、營(yíng)商能夠更嚴(yán)密控制他們的無(wú)線網(wǎng)絡(luò)基礎(chǔ)架構(gòu)。1-1目標(biāo)capwap 協(xié)議的目標(biāo)是：1、為了集中無(wú)線網(wǎng)絡(luò)的認(rèn)證功能和策略執(zhí)行功能。ac 也可以提供集中的橋接、轉(zhuǎn)發(fā)和用戶(hù)流量加密。通過(guò)在無(wú)線網(wǎng)絡(luò)更多使用網(wǎng)絡(luò)處理芯片能力，類(lèi)似有線 lans 經(jīng)歷的：集中這些功能將降低成本，提高效率。2、為了能夠?qū)⑤^高層協(xié)議處理從 wtp 轉(zhuǎn)出。把時(shí)間敏感的無(wú)線控制應(yīng)用和接入應(yīng)用留在 wtp，從而提高 wtps 中有限計(jì)算能力的使用效率，這些應(yīng)用現(xiàn)在受到嚴(yán)重成本壓力。3、為了提供不受限于特定無(wú)線技術(shù)的可擴(kuò)展協(xié)議。采用通用的封裝和傳輸機(jī)制獲得可擴(kuò)展性，使得將來(lái)通過(guò)特定無(wú)線綁定， capwap 協(xié)議能夠用于許多接入點(diǎn)類(lèi)型。

19、 capwap 協(xié)議僅關(guān)注 wtp 和 ac 間的接口。ac 間和站到 ac 的通信嚴(yán)格講超出這個(gè)文檔范圍。1-2本文檔中的約定本文檔中出現(xiàn)的術(shù)語(yǔ)“must”、“must not”、“required”、“shall”、 “shall not”、“should”、“should not”、“recommended”、“may”和“optional”的含義，遵循rfc 2119rfc2119描述。1-3特約作者這一節(jié)呈上對(duì)本標(biāo)準(zhǔn)重要內(nèi)容和概念做出貢獻(xiàn)的作者，并向他們致謝。capwap working group 選擇 lightweight access point protocol (lwap

20、p) lwapp為capwap 協(xié)議規(guī)范的基礎(chǔ)。lwapp 文檔的作者為：bob oharaemail: pat calhoun, cisco systems, inc.170 west tasman drive, san jose, ca 95134phone: +1 408-902-3240, email: rohit suri, cisco systems, inc.170 west tasman drive, san jose, ca 95134phone: +1 408-853-5548, email: rs

21、nancy cam winget, cisco systems, inc.170 west tasman drive, san jose, ca 95134phone: +1 408-853-0532, email: scott kelly, aruba networks1322 crossman ave, sunnyvale, ca 94089phone: +1 408-754-8408, email: michael glenn williams, nokia, inc.313 fair

22、child drive, mountain view, ca 94043phone: +1 650-714-7758, email: michael.g.williamsnsue hares, green hills software825 victors way, suite 100, ann arbor, mi 48108phone: +1 734 222 1610, email: datagram transport layer security (dtls) rfc4347被用作 capwap 協(xié)議的安全解決方案。本文檔中與 dtls 有關(guān)的

23、重要內(nèi)容的作者為：scott kelly, aruba networks1322 crossman ave, sunnyvale, ca 94089phone: +1 408-754-8408email: eric rescorla, network resonance2483 el camino real, #212,palo alto ca, 94303email: dtls 概念的使用確保 capwap 協(xié)議成為 secure light access point protocol (slapp)

24、建議 slapp的一部分。slapp 建議的作者為：partha narasimhan, aruba networks1322 crossman ave, sunnyvale, ca 94089phone: +1 408-480-4716email: dan harkins, trapeze networks5753 w. las positas blvd, pleasanton, ca 94588phone: +1-925-474-2212email: subbu ponnuswamy, aruba network

25、s1322 crossman ave, sunnyvale, ca 94089phone: +1 408-754-1213email: 為撰寫(xiě)rfc5418文檔所涉及安全部分內(nèi)容作出重要貢獻(xiàn)的人士有：t. charles clancy, laboratory for telecommunications sciences, 8080 greenmead drive, college park, md 20740 phone: +1 240-373-5069, email: scott kelly, aruba netw

26、orks1322 crossman ave, sunnyvale, ca 94089phone: +1 408-754-8408, email: 1-4術(shù)語(yǔ) access controller (ac)訪問(wèn)控制。在數(shù)據(jù)平面、控制平面、管理平面，或它們的組合中，將 wtp 接入到網(wǎng)絡(luò)基礎(chǔ)設(shè)施的網(wǎng)絡(luò)實(shí)體。 capwap control channelcapwap 控制通道。由 ac ip address、wtp ip address、ac 控制端口、wtp 控制端口和傳輸層協(xié)議(udp 或 udp-lite)定義的雙向流，在其上發(fā)送和接收 capwap c

27、ontrol 分組。 capwap data channelcapwap 數(shù)據(jù)通道。由 ac ip address、wtp ip address、ac 數(shù)據(jù)端口、wtp 數(shù)據(jù)端口和傳輸層協(xié)議(udp 或 udp-lite)定義的雙向流，在其上發(fā)送和接收 capwap data 分組。 station (sta)站(sta)。包含到無(wú)線媒介(wireless medium, wm)接口的設(shè)備。 wireless termination point (wtp)無(wú)線終端點(diǎn)(wtp)。包括射頻天線和無(wú)線物理層(phy)的物理或網(wǎng)絡(luò)實(shí)體，主要功能是發(fā)送和接收無(wú)線接入網(wǎng)絡(luò)的站流量。本文檔使用rfc3753

28、中定義的補(bǔ)充術(shù)語(yǔ)。第 2 章協(xié)議綜述capwap 協(xié)議是通用協(xié)議，它定義通過(guò) capwap 協(xié)議傳輸機(jī)制，進(jìn)行 ac 和 wtp 控制和數(shù)據(jù)平面通信。capwap control 消息，和可選的 capwap data 消息，使用 datagram transport layer security(dtls) rfc4347進(jìn)行安全保護(hù)。dtls 是源于 tls 的標(biāo)準(zhǔn)跟蹤 ietf協(xié)議。tls 的基礎(chǔ)安全相關(guān)協(xié)議機(jī)制已經(jīng)成功部署許多年。capwap 協(xié)議傳輸層攜帶兩類(lèi)凈荷，capwap data 消息和 capwap control 消息。 capwap data 消息封裝轉(zhuǎn)發(fā)的無(wú)線幀。ca

29、pwap control 消息是 wtp 和 ac 間交換的管理消息。capwap data 分組和 control 分組在分開(kāi)的 udp 端口上發(fā)送。因?yàn)閿?shù)據(jù)分組和控制分組可能都超過(guò) maximum transmission unit (mtu)長(zhǎng)度，capwap data 或 control 消息的凈荷可能需要分段。第 3 章定義分段處理。capwap protocol 由 discovery 階段開(kāi)始。wtps 發(fā)送 discovery request 消息，誘發(fā)任何收到該消息的 ac 用 discovery response 消息響應(yīng)。根據(jù)收到的 discovery response

30、消息， wtp 用與其建立安全的 dtls 會(huì)話(huà)來(lái)選擇一個(gè) ac。為了建立安全的 dtls 連接，wtp 需要做某些預(yù)配置，預(yù)配置在第 12-5 節(jié)介紹。根據(jù)發(fā)現(xiàn)的、網(wǎng)絡(luò)能支持的最大長(zhǎng)度，分段 capwap 協(xié)議消息。一旦 wtp 和 ac 完成 dtls 會(huì)話(huà)建立，開(kāi)始配置交換，其間兩個(gè)設(shè)備對(duì)采用的版本達(dá)成一致。在這個(gè)交換中，wtp 可以接收配置設(shè)置。然后，wtp 開(kāi)始運(yùn)行。當(dāng) wtp 和 ac 完成版本和配置交換并啟動(dòng) wtp 后，capwap 協(xié)議用于封裝在 wtp和 ac 見(jiàn)發(fā)送的無(wú)線數(shù)據(jù)幀。如果被封裝的無(wú)線用戶(hù)數(shù)據(jù)(data)幀或協(xié)議控制(management)幀的長(zhǎng)度引起最終的 c

31、apwap 協(xié)議分組超過(guò) wtp 和 ac 間支持的 mtu，capwap 協(xié)議將分段第 2 層幀。為了重建原始封裝的凈荷，被分段的 capwap 分組被重組。mtu discovery and fragmentation 在第 3 章介紹。capwap protocol 由 discovery 階段開(kāi)始。wtps 發(fā)送 discovery request 消息，誘發(fā)任何收到該消息的 ac 用 discovery response 消息響應(yīng)。根據(jù)收到的 discovery response 消息，wtp 用與其建立安全的 dtls 會(huì)話(huà)來(lái)選擇一個(gè) ac。為了建立安全的 dtls 連接，wtp

32、需要一些預(yù)配置，預(yù)配置在第 12-5 節(jié)介紹。根據(jù)發(fā)現(xiàn)的、網(wǎng)絡(luò)能支持的最大長(zhǎng)度，分段 capwap協(xié)議消息。一旦 wtp 和 ac 完成 dtls 會(huì)話(huà)建立，開(kāi)始配置交換，其間兩個(gè)設(shè)備對(duì)采用的版本達(dá)成一致。在這個(gè)交換中，wtp 可以接收配置設(shè)置。然后，wtp 開(kāi)始運(yùn)行。當(dāng) wtp 和 ac 完成版本和配置交換并啟動(dòng) wtp 后，capwap 協(xié)議用于封裝在 wtp和 ac 間發(fā)送的無(wú)線數(shù)據(jù)幀。如果被封裝的無(wú)線用戶(hù)數(shù)據(jù)(data)幀或協(xié)議控制(management)幀的長(zhǎng)度引起最終的 capwap 協(xié)議分組超過(guò) wtp 和 ac 間支持的 mtu，capwap 協(xié)議將分段第 2 層幀。為了重建原

33、始封裝的凈荷，分段的 capwap 分組被重組。mtu discovery and fragmentation 在第 3 章介紹。capwap 協(xié)議提供從 ac 到 wtp 的指令傳送，這些指令用于管理與 wtp 通信的站。這可以包括在 wtp 中建立這些站的本地?cái)?shù)據(jù)結(jié)構(gòu)，以及收集有關(guān) wtp 與這些站間通信的統(tǒng)計(jì)信息。capwap 協(xié)議為 ac 提供機(jī)制，以便獲得由 wtp 收集的統(tǒng)計(jì)信息。capwap 協(xié)議提供保持激活(keep-alive)功能，該功能保持 wtp 和 ac 間的通信信道。如果該 ac 沒(méi)有顯現(xiàn)激活，wtp 將嘗試發(fā)現(xiàn)新的 ac。2-1無(wú)線綁定定義capwap 協(xié)議與特定

34、 wtp 無(wú)線電設(shè)備技術(shù)無(wú)關(guān)，也與它的相關(guān)無(wú)線鏈路層協(xié)議無(wú)關(guān)。 capwap 協(xié)議的各個(gè)部分采用標(biāo)準(zhǔn)方法設(shè)計(jì)，適應(yīng)每一種無(wú)線技術(shù)的特定需要。具體無(wú)線技術(shù)采用的 capwap 協(xié)議必須遵循為那個(gè)技術(shù)定義的綁定要求。定義無(wú)線技術(shù)綁定時(shí)，編寫(xiě)者必須包括任何特定技術(shù)消息的必要定義，以及所有這些消息的特定技術(shù)消息要素(message elements)。最低限度，綁定必須提供：1、在 wtp event request 消息中攜帶的、特定綁定 statistics 消息要素的定義。2、在 station configuration request 消息中攜帶的，在 wtp 上配置站信息的消息要素。3、在

35、 discovery、primary discovery 以及 join request 和 response 消息中攜帶的，指出在 wtp 和 ac 中支持的特定綁定無(wú)線電設(shè)備類(lèi)型的 wtp radio information 消息要素。如果對(duì)于本標(biāo)準(zhǔn)中定義的任何現(xiàn)有 capwap 消息要求有特定技術(shù)消息要素，這些消息要素也必須在技術(shù)綁定文檔中定義。特定綁定消息要素的命名必須以技術(shù)類(lèi)型名稱(chēng)開(kāi)始，例如，ieee 802.11 綁定，在rfc5416中提供，以“ieee 802.11”開(kāi)始。capwap綁定概念也必須在任何將來(lái)的規(guī)范中使用，這些將來(lái)的規(guī)范將功能添加到基本capwap協(xié)議規(guī)范，或者

36、添加到任何發(fā)布的capwap綁定規(guī)范。必須生成獨(dú)立的wtp radio information消息要素，以便適當(dāng)通告對(duì)規(guī)范的支持。這個(gè)機(jī)制為將來(lái)協(xié)議擴(kuò)展做好準(zhǔn)備，在提供必要能力通告的同時(shí)，通過(guò)wtp radio information要素，確保wtp/ac可互操作。2-2capwap 會(huì)話(huà)建立綜述本節(jié)介紹 capwap wtp 和 ac 間會(huì)話(huà)建立處理消息交換。帶注釋梯形圖顯示 ac 在右邊，wtp 在左邊，并假設(shè)使用 dtls 認(rèn)證證書(shū)。capwap 協(xié)議狀態(tài)機(jī)在第 2-3 節(jié)詳細(xì)介紹。注意，dtls 允許將一定數(shù)量消息聚合到單一幀，這在圖 3 中用星號(hào)表示。wtpac開(kāi)始可選的發(fā)現(xiàn)disc

37、over requestdiscover response結(jié)束可選的發(fā)現(xiàn)( - 開(kāi)始dtls握手 - )clienthellohelloverifyrequest (帶cookie)clienthello (帶cookie)serverhello,certificate,serverhellodone*( - ac授權(quán)的wtp呼出 - )certificate (可選),clientkeyexchange,certificateverify (可選),changecipherspec,finished*( - wtp授權(quán)的ac呼出 - )changecipherspec,finished*(

38、- 現(xiàn)在建立dtls會(huì)話(huà) - )join requestjoin response圖 3capwap 控制協(xié)議交換wtpac - 加入狀態(tài)完成 - ( - 假設(shè)圖像被更新 - )configuration status requestconfiguration status response - 配置狀態(tài)完成 - change state event requestchange state event response - 數(shù)據(jù)核查狀態(tài)完成 - ( - 進(jìn)入run狀態(tài)- )：echo requestecho response：event requestevent response：圖 3 續(xù)c

39、apwap 控制協(xié)議交換在上圖所示的 capwap 消息交換末尾，ac 和 wtp 正在安全交換 capwap control 消息。這個(gè)圖示用于澄清協(xié)議操作，不包括任何可能的錯(cuò)誤條件。第 2-3 節(jié)詳細(xì)介紹相應(yīng)狀態(tài)機(jī)。2-3capwap 狀態(tài)機(jī)定義下述狀態(tài)圖表示 wtp-ac 會(huì)話(huà)生命周期。由于 capwap 協(xié)議使用 dtls，導(dǎo)致兩個(gè)名義上獨(dú)立然而緊密綁定的狀態(tài)機(jī)并置。通過(guò)由指令(參閱第 2-3-2-1 節(jié))和通知(參閱第 2-3-2-2 節(jié))構(gòu)成的 api，dtls 狀態(tài)機(jī)和 capwap 狀態(tài)機(jī)耦合在一起。capwap 狀態(tài)機(jī)的某些指令觸發(fā) dtls 狀態(tài)機(jī)中的某些轉(zhuǎn)換，而 dtls

40、 狀態(tài)機(jī)中的某些通知觸發(fā) capwap 狀態(tài)機(jī)中的某些轉(zhuǎn)換。pqrrunresetsnodata checkfknmhjjoinconfigureimage datagil4dtdtls setupdtls connectdtls td6e$5w31%#abidlediscauthorizedead20！*ustartsulking&圖 4capwap 集成的狀態(tài)機(jī)如上所述，capwap 協(xié)議狀態(tài)機(jī)由 ac 和 wtp 使用。如果是這些狀態(tài)不被共享情況(即， ac 或 wtp 的一方或另一方?jīng)]有執(zhí)行)，在下面介紹的轉(zhuǎn)換中會(huì)顯式標(biāo)出。對(duì)于每一種定義的狀態(tài)，僅準(zhǔn)許發(fā)送和接收某些消息。狀態(tài)由 cap

41、wap control 消息定義規(guī)定，在這些狀態(tài)中每個(gè)消息是合法的。因?yàn)?wtp 僅與單個(gè) ac 通信，wtp 僅有單個(gè) capwap 狀態(tài)機(jī)實(shí)例。在 ac 上狀態(tài)機(jī)的工作與此不同，因?yàn)?ac 與許多 wtps 通信。ac 使用 3 個(gè)線程概念。注意，這里使用線程術(shù)語(yǔ)沒(méi)有暗示實(shí)現(xiàn)必須使用線程，但是它是實(shí)現(xiàn) ac 狀態(tài)機(jī)的一種可選方法。listener thread：ac 的 listener 線程通過(guò) dtlslisten 指令，處理入境 dtls 會(huì)話(huà)建立請(qǐng)求。創(chuàng)建后，listener 線程在 dtls setup 狀態(tài)中啟動(dòng)。一旦 dtls 會(huì)話(huà)通過(guò)驗(yàn)證(當(dāng)狀態(tài)機(jī)進(jìn)入“authorize”

42、狀態(tài)時(shí)發(fā)生)，listener 線程創(chuàng)建 wtp 特定會(huì)話(huà) service 線程和狀態(tài)上下文。在圖 4 中這些狀態(tài)機(jī)轉(zhuǎn)換由數(shù)字表示。ac 必須保護(hù)自己，抵御存在于未認(rèn)證幀的各種攻擊。更多信息參閱第 12 章。discovery thread：ac 的 discovery 線程負(fù)責(zé)接收和響應(yīng) discovery request 消息。在圖4 中這些狀態(tài)機(jī)轉(zhuǎn)換由數(shù)字表示。注意，discovery 線程不保留任何每個(gè) wtp 特定上下文信息，并且單個(gè)狀態(tài)上下文存在。ac 必須保護(hù)自己，抵御存在于未認(rèn)證幀的各種攻擊。更多信息參閱第 12 章。service thread：ac 的 service 線程

43、處理每個(gè) wtp 狀態(tài)，并且每個(gè) wtp 連接有一個(gè)這樣的線程。這個(gè)線程由 listener 線程在達(dá)到 authorize 狀態(tài)時(shí)創(chuàng)建。創(chuàng)建時(shí)，service線程繼承來(lái)自 listener 線程的狀態(tài)機(jī)上下文副本。當(dāng)與 wtp 的通信完成時(shí)，service線程終止并且釋放所有關(guān)聯(lián)的資源。圖 4 中這些狀態(tài)機(jī)轉(zhuǎn)換由字母和標(biāo)點(diǎn)符號(hào)表示。第 2-3-1capwap 協(xié)議狀態(tài)轉(zhuǎn)換本節(jié)介紹各種狀態(tài)機(jī)，以及誘發(fā)它們的事件。本節(jié)不討論特定 dtls 狀態(tài)和特定 capwap 狀態(tài)間的互動(dòng)。這些互動(dòng)，以及 dtlsspecific 狀態(tài)和轉(zhuǎn)換，在第 2-3-2 節(jié)討論。 start 到 idle (0)：一

44、旦設(shè)備初始化完成，這個(gè)轉(zhuǎn)換發(fā)生。wtp：這個(gè)狀態(tài)轉(zhuǎn)換用于啟動(dòng) wtp 的 capwap 狀態(tài)機(jī)。ac： ac 創(chuàng)建 discovery 線程和 listener 線程，并啟動(dòng) capwap 狀態(tài)機(jī)。idle 到 discovery (1)：為了支持 capwap 發(fā)現(xiàn)處理，這個(gè)轉(zhuǎn)換發(fā)生。wtp：在傳送第一個(gè) discovery request 消息前 wtp 進(jìn)入 discovery 狀態(tài)(參閱第 5-1 節(jié))。一旦進(jìn)入這個(gè)狀態(tài)，wtp 設(shè)置 discoveryinterval 計(jì)時(shí)器(參閱第 4-7 節(jié))。wtp 重新設(shè)置 discoverycount 計(jì)數(shù)器到 0(參閱第 4-8 節(jié))。w

45、tp 也清除在前一個(gè) discovery 階段它可能收到的、來(lái)自 acs 的所有信息。ac： 這個(gè)狀態(tài)轉(zhuǎn)換由 ac 的 discovery 線程執(zhí)行，當(dāng)收到 discovery request 消息時(shí)發(fā)生。ac 應(yīng)當(dāng)用 discovery response 消息響應(yīng)(參閱第 5-2 節(jié))。discovery 到 discovery (#)：在 discovery 狀態(tài)，wtp 決定連接到哪一個(gè) ac。wtp：當(dāng) discoveryinterval 計(jì)時(shí)器到期，這個(gè)轉(zhuǎn)換發(fā)生。如果 wtp 由一組 acs 配置， wtp 傳送 discovery request 消息到每個(gè) ac(wtp 還沒(méi)有從該 ac 收到 discovery response 消息)。這個(gè)事件每轉(zhuǎn)換一次，wtp 都增加 discoverycount 計(jì)數(shù)器。關(guān)于 wtp 如何知道這些 acs 是它應(yīng)當(dāng)發(fā)送 discovery reque