計(jì)算機(jī)外文翻譯9

上傳人：奔*** IP屬地：河北更新時(shí)間：2024-03-01 格式：doc 頁(yè)數(shù)：56 大?。?40.00KB 人氣指數(shù)：12 舉報(bào) 版權(quán)申訴

已閱讀1頁(yè)，還剩55頁(yè)未讀，繼續(xù)免費(fèi)閱讀

版權(quán)說(shuō)明：本文檔由用戶提供并上傳，收益歸屬內(nèi)容提供方，若內(nèi)容存在侵權(quán)，請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、　　RFC 5415 CAPWAP Protocol Specification March 2009　　2. Protocol Overview　　The CAPWAP protocol is a generic protocol defining AC and WTP control&

2、lt;/p>　　and data plane communication via a CAPWAP protocol transport　　mechanism. CAPWAP Control messages, and optionally CAPWAP Data　　messages, are secured using D

3、atagram Transport Layer Security (DTLS)　　[RFC4347]. DTLS is a standards-track IETF protocol based upon TLS.　　The underlying security-related protocol mechanisms of TLS have been

4、　　successfully deployed for many years.　　The CAPWAP protocol transport layer carries two types of payload,　　CAPWAP Data messages and CAPWAP Control messages.

5、 CAPWAP Data　　messages encapsulate forwarded wireless frames. CAPWAP protocol　　Control messages are management messages exchanged between a WTP and　　an AC.

6、 The CAPWAP Data and Control packets are sent over separate　　UDP ports. Since both data and control packets can exceed the　　Maximum Transmission Unit (MTU) length, the payload

7、of a CAPWAP Data　　or Control message can be fragmented. The fragmentation behavior is　　defined in Section 3.　　The CAPWAP Protocol begins with a Discovery ph

8、ase. The WTPs send a　　Discovery Request message, causing any Access Controller (AC)　　receiving the message to respond with a Discovery Response message.　　Fr

9、om the Discovery Response messages received, a WTP selects an AC　　with which to establish a secure DTLS session. In order to establish　　the secure DTLS connection, the WTP will

10、need some amount of pre-　　provisioning, which is specified in Section 12.5. CAPWAP protocol　　messages will be fragmented to the maximum length discovered to be<p&

11、gt;　　supported by the network.　　Once the WTP and the AC have completed DTLS session establishment, a　　configuration exchange occurs in which both devices agree on version</p&g

12、t;　　information. During this exchange, the WTP may receive provisioning　　settings. The WTP is then enabled for operation.　　When the WTP and AC have completed the ver

13、sion and provision exchange　　and the WTP is enabled, the CAPWAP protocol is used to encapsulate　　the wireless data frames sent between the WTP and AC. The CAPWAP<

14、p>　　protocol will fragment the L2 frames if the size of the encapsulated　　wireless user data (Data) or protocol control (Management) frames　　causes the resulting CAPWAP protoc

15、ol packet to exceed the MTU　　supported between the WTP and AC. Fragmented CAPWAP packets are　　reassembled to reconstitute the original encapsulated payload. MTU<

16、p>　　Discovery and Fragmentation are described in Section 3.　　The CAPWAP protocol provides for the delivery of commands from the AC　　to the WTP for the management of stations t

17、hat are communicating with　　the WTP. This may include the creation of local data structures in　　the WTP for the stations and the collection of statistical

18、information about the communication between the WTP and the stations.　　The CAPWAP protocol provides a mechanism for the AC to obtain　　statistical information collected by the WTP

19、.　　The CAPWAP protocol provides for a keep-alive feature that preserves　　the communication channel between the WTP and AC. If the AC fails to　　appear alive,

20、 the WTP will try to discover a new AC.　　2.1. Wireless Binding Definition　　The CAPWAP protocol is independent of a specific WTP radio　　technology, as well i

21、ts associated wireless link layer protocol.　　Elements of the CAPWAP protocol are designed to accommodate the　　specific needs of each wireless technology in a standard way.</p&

22、gt;　　Implementation of the CAPWAP protocol for a particular wireless　　technology MUST follow the binding requirements defined for that　　technology.

23、;　　When defining a binding for wireless technologies, the authors MUST　　include any necessary definitions for technology-specific messages　　and all technology-specific message el

24、ements for those messages. At　　a minimum, a binding MUST provide:　　1. The definition for a binding-specific Statistics message element,　　carried in the WTP

25、Event Request message.　　2. A message element carried in the Station Configuration Request　　message to configure station information on the WTP.　　3. A WTP Rad

26、io Information message element carried in the Discovery,　　Primary Discovery, and Join Request and Response messages,　　indicating the binding-specific radio types supported at the

27、 WTP　　and AC.　　If technology-specific message elements are required for any of the　　existing CAPWAP messages defined in this specification

28、, they MUST　　also be defined in the technology binding document.　　The naming of binding-specific message elements MUST begin with the　　name of the technology

29、 type, e.g., the binding for IEEE 802.11,　　provided in [RFC5416], begins with "IEEE 802.11".　　The CAPWAP binding concept MUST also be used in any future<

30、p>　　specifications that add functionality to either the base CAPWAP　　protocol specification, or any published CAPWAP binding　　specification. A separate WTP Radio Information

31、message element MUST　　be created to properly advertise support for the specification. This　　mechanism allows for future protocol extensibility, while providing<p&

32、gt;　　the necessary capabilities advertisement, through the WTP Radio　　Information message element, to ensure WTP/AC interoperability.　　2.2. CAPWAP Session Establishment Overview

33、　　This section describes the session establishment process message　　exchanges between a CAPWAP WTP and AC. The annotated ladder diagram　　shows the AC on the

34、 right, the WTP on the left, and assumes the use　　of certificates for DTLS authentication. The CAPWAP protocol state　　machine is described in detail in Section 2.3. Note that D

35、TLS allows　　certain messages to be aggregated into a single frame, which is　　denoted via an asterisk in Figure 3.　　============ =====

36、=======　　WTP AC　　============ ============　　[----------- begin optional discovery ------------]<

37、/p>　　Discover Request　　------------------------------------>　　Discover Response　　<------------------------------------<p&g

38、t;　　[----------- end optional discovery ------------]　　(-- begin DTLS handshake --)　　ClientHello　　------------------------------------><p&g

39、t;　　HelloVerifyRequest (with cookie)　　<------------------------------------　　ClientHello (with cookie)　　------------------------------------>

40、　　ServerHello,　　Certificate,　　ServerHelloDone*　　<------------------------------------　　(-- WTP callout for AC authorizatio

41、n --)　　Certificate (optional),　　ClientKeyExchange,　　CertificateVerify (optional),　　ChangeCipherSpec,　　Fini

42、shed*　　------------------------------------>　　(-- AC callout for WTP authorization --)　　ChangeCipherSpec,　　Finishe

43、d*　　<------------------------------------　　(-- DTLS session is established now --)　　Join Request　　-------------------------

44、----------->　　Join Response　　<------------------------------------　　[-- Join State Complete --]　　(-- assume image is up to date --

45、)　　Configuration Status Request　　------------------------------------>　　Configuration Status Response　　<--------------------------

46、----------　　[-- Configure State Complete --]　　Change State Event Request　　------------------------------------>　　Change State Event R

47、esponse　　<------------------------------------　　[-- Data Check State Complete --]　　(-- enter RUN state --)　　:</

48、p>　　:　　Echo Request　　------------------------------------>　　Echo Response　　<---------------------

49、---------------　　:　　:　　Event Request　　------------------------------------>

50、;　　Event Response　　<------------------------------------　　:　　:　　Figure 3: CAPWAP Control Protoc

51、ol Exchange　　At the end of the illustrated CAPWAP message exchange, the AC and WTP　　are securely exchanging CAPWAP Control messages. This illustration　　is p

52、rovided to clarify protocol operation, and does not include any　　possible error conditions. Section 2.3 provides a detailed　　description of the corresponding state machine.</

53、p>　　2.3. CAPWAP State Machine Definition　　The following state diagram represents the lifecycle of a WTP-AC　　session. Use of DTLS by the CAPWAP protocol results in

54、 the　　juxtaposition of two nominally separate yet tightly bound state　　machines. The DTLS and CAPWAP state machines are coupled through an　　API consisting o

55、f commands (see Section 2.3.2.1) and notifications　　(see Section 2.3.2.2). Certain transitions in the DTLS state machine　　are triggered by commands from the CAPWAP state machine

56、, while　　certain transitions in the CAPWAP state machine are triggered by　　notifications from the DTLS state machine.　　/-------------------------------------

57、\　　| /-------------------------\|　　| p| ||　　| q+----------+ r +------------+ ||　　| |

58、Run |-->| Reset |-\||　　| +----------+ +------------+ |||　　n| o ^ ^ ^ s|||　　+------------+--------/ |

59、| |||　　| Data Check | /-------/ | |||　　+------------+<-------\ | | |||　　| | | |||</p

60、>　　/------------------+--------\ | |||　　f| m| h| j v k| |||　　+--------+ +-----------+ +--------------+|||<

61、p>　　| Join |---->| Configure | | Image Data ||||　　+--------+ n +-----------+ +--------------+|||　　^ |g i| l| |||

62、;　　| | \-------------------\ | |||　　| \--------------------------------------\| | |||　　\------------------------\ || | |||</p&

63、gt;　　/--------------<----------------+---------------\ || | |||　　| /------------<----------------+-------------\ | || | |||　　| | 4 |d

64、 t| | vv v vvv　　| | +----------------+ +--------------+ +-----------+　　| | | DTLS Setup | | DTLS Connect |-->| DTLS TD |　　/-|-|---

65、+----------------+ +--------------+ e +-----------+　　| | | |$ ^ ^ |5 ^6 ^ ^ |w　　v v v | | | | \-------\ | | |

66、　　| | | | | | \---------\ | | /-----------/ |　　| | | | | \--\ | | | | |　　| | | | | | | | | | |&

67、lt;/p>　　| | | v 3| 1 |% # v | |a |b v　　| | \->+------+-->+------+ +-----------+ +--------+　　| | | Idle | | Disc | | Autho

68、rize | | Dead |　　| | +------+<--+------+ +-----------+ +--------+　　| | ^ 0^ 2 |!　　| | | | | +-------+

69、　　*| |u | \---------+---| Start |　　| | |@ | +-------+　　| \->+---------+<------/　　\--->| Sulking |<p

70、>　　+---------+&　　Figure 4: CAPWAP Integrated State Machine　　The CAPWAP protocol state machine, depicted above, is used by both　　the AC and the WTP. I

71、n cases where states are not shared (i.e., not　　implemented in one or the other of the AC or WTP), this is explicitly　　called out in the transition descriptions below. For every

72、 state　　defined, only certain messages are permitted to be sent and received.　　The CAPWAP Control message definitions specify the state(s) in which　　each mes

73、sage is valid.　　Since the WTP only communicates with a single AC, it only has a　　single instance of the CAPWAP state machine. The state machine works　　diffe

74、rently on the AC since it communicates with many WTPs. The AC　　uses the concept of three threads. Note that the term thread used　　here does not necessarily imply that implement

75、ers must use threads,　　but it is one possible way of implementing the AC's state machine.　　Listener Thread: The AC's Listener thread handles inbound DTLS<

76、;p>　　session establishment requests, through the DTLSListen command.　　Upon creation, the Listener thread starts in the DTLS Setup state.　　Once a DTLS session has been validate

77、d, which occurs when the　　state machine enters the "Authorize" state, the Listener thread　　creates a WTP session-specific Service thread and state context.&

78、lt;p>　　The state machine transitions in Figure 4 are represented by　　numerals. It is necessary for the AC to protect itself against　　various attacks that exist with non-authe

79、nticated frames. See　　Section 12 for more information.　　Discovery Thread: The AC's Discovery thread is responsible for　　receiving, and responding to,

80、Discovery Request messages. The　　state machine transitions in Figure 4 are represented by numerals.　　Note that the Discovery thread does not maintain any per-WTP-<

81、;p>　　specific context information, and a single state context exists.　　It is necessary for the AC to protect itself against various　　attacks that exist with non-authenticated

82、frames. See Section 12　　for more information.　　Service Thread: The AC's Service thread handles the per-WTP states,　　and one such thread exists per-WTP

83、 connection. This thread is　　created by the Listener thread when the Authorize state is　　reached. When created, the Service thread inherits a copy of the

84、state machine context from the Listener thread. When　　communication with the WTP is complete, the Service thread is　　terminated and all associated resources are released. The s

85、tate　　machine transitions in Figure 4 are represented by alphabetic and　　punctuation characters.　　2.3.1. CAPWAP Protocol State Transitions<p&

86、gt;　　This section describes the various state transitions, and the events　　that cause them. This section does not discuss interactions between　　DTLS- and CAPWAP-specific states.

87、 Those interactions, and DTLS-　　specific states and transitions, are discussed in Section 2.3.2.　　Start to Idle (0): This transition occurs once device initialization

88、　　is complete.　　WTP: This state transition is used to start the WTP's CAPWAP　　state machine.　　AC: The AC creates the Discovery and Listener

89、 threads and starts　　the CAPWAP state machine.　　Idle to Discovery (1): This transition occurs to support the CAPWAP　　discovery process.

90、　　WTP: The WTP enters the Discovery state prior to transmitting the　　first Discovery Request message (see Section 5.1). Upon　　entering this state, the WTP sets the DiscoveryInt

91、erval　　timer (see Section 4.7). The WTP resets the DiscoveryCount　　counter to zero (0) (see Section 4.8). The WTP also clears　　all information from ACs it

92、may have received during a　　previous Discovery phase.　　AC: This state transition is executed by the AC's Discovery　　thread, and occurs when a Discovery

93、 Request message is　　received. The AC SHOULD respond with a Discovery Response　　message (see Section 5.2).　　Discovery to Discovery (#): In the Discovery st

94、ate, the WTP　　determines to which AC to connect.　　WTP: This transition occurs when the DiscoveryInterval timer　　expires. If the WTP is configured with a li

95、st of ACs, it　　transmits a Discovery Request message to every AC from which　　it has not received a Discovery Response message. For every　　transition to this

96、 event, the WTP increments the　　DiscoveryCount counter. See Section 5.1 for more　　information on how the WTP knows the ACs to which it should　　transmit the

97、Discovery Request messages. The WTP restarts　　the DiscoveryInterval timer whenever it transmits Discovery　　Request messages.　　AC: This is an invalid state

98、 transition for the AC.　　Discovery to Idle (2): This transition occurs on the AC's Discovery　　thread when the Discovery processing is complete.　　WTP: T

99、his is an invalid state transition for the WTP.　　AC: This state transition is executed by the AC's Discovery　　thread when it has transmitted the Discovery Response, in</

100、p>　　response to a Discovery Request.　　Discovery to Sulking (!): This transition occurs on a WTP when AC　　Discovery fails.　　WTP: The WTP enter

101、s this state when the DiscoveryInterval timer　　expires and the DiscoveryCount variable is equal to the　　MaxDiscoveries variable (see Section 4.8). Upon entering<p

102、>　　this state, the WTP MUST start the SilentInterval timer.　　While in the Sulking state, all received CAPWAP protocol　　messages MUST be ignored.　　AC: Th

103、is is an invalid state transition for the AC.　　Sulking to Idle (@): This transition occurs on a WTP when it must　　restart the Discovery phase.　　WTP: The WT

104、P enters this state when the SilentInterval timer (see　　Section 4.7) expires. The FailedDTLSSessionCount,　　DiscoveryCount, and FailedDTLSAuthFailCount counters are&l

105、t;p>　　reset to zero.　　AC: This is an invalid state transition for the AC.　　Sulking to Sulking (&): The Sulking state provides the silent　　period, m

106、inimizing the possibility for Denial-of-Service (DoS)　　attacks.　　WTP: All packets received from the AC while in the sulking state　　are ig

107、nored.　　AC: This is an invalid state transition for the AC.　　Idle to DTLS Setup (3): This transition occurs to establish a secure　　DTLS session with the p

108、eer.　　WTP: The WTP initiates this transition by invoking the DTLSStart　　command (see Section 2.3.2.1), which starts the DTLS session　　establishment with the

109、 chosen AC and the WaitDTLS timer is　　started (see Section 4.7). When the Discovery phase is　　bypassed, it is assumed the WTP has locally configured ACs.　　A

110、C: Upon entering the Idle state from the Start state, the newly　　created Listener thread automatically transitions to the　　DTLS Setup and invokes the DTLSListen command (see<

111、;/p>　　Section 2.3.2.1), and the WaitDTLS timer is started (see　　Section 4.7).　　Discovery to DTLS Setup (%): This transition occurs to establish a<p&

112、gt;　　secure DTLS session with the peer.　　WTP: The WTP initiates this transition by invoking the DTLSStart　　command (see Section 2.3.2.1), which starts the DTLS session

眾賞文庫(kù)> 全部分類> 畢業(yè)設(shè)計(jì)

溫馨提示

1. 本站所有資源如無(wú)特殊說(shuō)明，都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
2. 本站的文檔不包含任何第三方提供的附件圖紙等，如果需要附件，請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
3. 本站RAR壓縮包中若帶圖紙，網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽，若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
5. 眾賞文庫(kù)僅提供信息存儲(chǔ)空間，僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理，對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯，并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容，請(qǐng)與我們聯(lián)系，我們立即糾正。
7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

計(jì)算機(jī)外文翻譯9

文檔簡(jiǎn)介

溫馨提示

最新文檔

評(píng)論

計(jì)算機(jī)外文翻譯9

文檔簡(jiǎn)介

溫馨提示

最新文檔

評(píng)論

免費(fèi)下載