Subject: Re: [Capwap] Data Channel Keep-alive Proposed Text

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 9 Jan 2007 10:55:51 -0800 (GMT-08:00)

I meant to reply to this proposal, but have been swamped. I think just putting the sessionid in keepalives should work fine provided that the there is logic defined for definitively establishing the data channel (e.g. a successful request/response exchange) prior to transmission of data (and of course, logic to handle the error cases), but I am concerned about the proposal to confine the keepalive facility to NAT'd connections.

The original arguments for the multiport approach posited the need for differential QoS on the data channel vs the control channel. This implies that they may follow different paths through the network. With no DC keepalive, there is a risk that the DC could be black-holed while CAPWAP remains oblivious. 

-----Original Message-----
>From: "Pat Calhoun (pacalhou)" <[email-masked]>
>Sent: Jan 9, 2007 10:27 AM
>To: Jim Murphy <[email-masked]>, capwap <[email-masked]>
>Subject: Re: [Capwap] Data Channel Keep-alive Proposed Text
>
>Jim, just to clarify, your proposal below assumes that the Session ID is
>a message element, correct?
>
>Pat Calhoun
>CTO, Wireless Networking Business Unit
>Cisco Systems
>
> 
>
>> -----Original Message-----
>> From: Jim Murphy [mailto:[email-masked]] 
>> Sent: Thursday, January 04, 2007 4:57 PM
>> To: capwap
>> Subject: [Capwap] Data Channel Keep-alive Proposed Text
>> 
>> 
>> There are two issues being resolved in this text.
>> 
>> The first issue is the need for a keep-alive in the data 
>> channel to ensure the maintenance of the NAT state.
>> 
>> The second is the need to map CAPWAP control channel to the 
>> corresponding CAPWAP data channel for a particular WTP.
>> 
>> Since the CAPWAP control channel and the CAPWAP data channel 
>> are operating on two different UDP ports, identifying to 
>> which control channel a data channel packet is associated 
>> requires a unique identifier in the data channel packet. In 
>> the case where no NAT device is present this is accomplished 
>> through the source IP address of incoming UDP packets. 
>> However, when a NAT device is present, the source IP 
>> addresses may not be the same as that used in the control 
>> channel and the source UDP port selected by the WTP may be 
>> modified by the NAT.
>> 
>> The following is proposed text to be included in the draft. 
>> This text was generated from the -03 specification.
>> 
>> Proposed Text
>> -------------
>> 
>> 2.3.  CAPWAP State Machine Definition
>> 
>>              /-------------<----------------+--------------------\
>>              v                              |d                   |
>>           +------+  b+-----------+    +----------+               |
>>           | Idle |-->| Discovery |--->|  Sulking |               |
>>           +------+ a +-----------+ c  +----------+               |
>>            ^   |aa    ^ |e            /----------------------\   |
>>            |   V     f| v            k|                      |   |
>>         h +--------------+  +------------+ i +------------+j |   |
>>        /--|    Join      |->|  Configure |-->| Image Data |  |   |
>>        |  +--------------+ g+------------+   +------------+  |   |
>>        |   "c1,  ^  ^   ^       m1|   m|       ^    |l       |   |
>>        |   "c4   "  "   "         V    \---\   |    |   /----/   |
>>        |   "     "  "   "   +------------+ |   |    |   |        |
>>        |   "     "  "   "   | Data Check | |   |    |   |        |
>>        |   "     "  "   "   +------------+ |   |    |   |        |
>>        |   "     "  "   "       m2|        |   |    |   |        |
>>        |   "     "  "   "         |  /-----/   |    |   |        |
>>        |   "     "  "   "         |  | /-------/    |   |        |
>>        |   "     "  "   "         V  V |s           v   V        |
>>        |   "     "  "   "   +------------+ o+------------+       |
>>        |   "     "  "   "   |    Run     |->|    Reset   |-------/
>>        |   "     "  "   "  n+------------+  +------------+   p
>>        |   "     "  "   "        "c2  ^       ^  c3"   ^
>>        \---"-----"--"---"--------"----"-------/    "   "     CAPWAP
>>     ~~~~~~~"~~~~~"~~"~~~"~~~~~~~~"~~~~"~~~~~~~~~~~~"~~~"~~~~~~~~~~~~
>>            "     "  "   "        "    "            "   "      DTLS
>>            v     "  "n2 \"""""\  "    "            v   "n6,n7
>>     /-->+------+ " W+------+  "  "    "      +------------+
>>     | /-| Idle | " C| Auth |--"~-"----"----->|  Shutdown  |-------\P
>>     | | +------+ "  +------+V "  "    " /--->|            |<----\ |
>>     | |X     Z|  "   ^  U|    "  " n4 " |    +------------+     | |
>>     | |       |  "   |   |    "  " n5," |         ^             | |
>>     | |       v  "n1 |Y  |  n3"  v  n8" |R        |Q            | |
>>     | |      +--------+  |  +------------+  S+------------+     | |
>>     | |      |  Init  |  \->|    Run     |<--|   Rekey    |     | |
>>     | |      +--------+     |            |-->|            |     | |
>>     | |                     +------------+T  +------------+     | |
>>     | \---------------------------------------------------------/ |
>>     \-------------------------------------------------------------/
>> 
>> 
>> [...]
>> 
>>     Configure to Data Check (m1): This state transition 
>> occurs when the
>>        WTP and AC determine that there exists a NAT device between the
>>        two (see Section 4.4.3.9 and Section 6.2).
>> 
>>      WTP:   The WTP enters this state when it receives a successful
>>        Configuration Status Response message from the AC.  The WTP
>>        initializes the HeartBeat timer (see Section 4.5), and
>>        transmits the Change State Event Request message (see
>>        Section 8.6). The WTP starts the DataChannelKeepAlive
>>        timer (see Section 4.5) and sends a data channel keep-alive
>>        packet. The WTP must also start the 
>> DataChannelDeadInterval timer
>>       (see Section 4.5).
>> 
>>      AC: This state transition occurs when the AC receives the Change
>>        State Event Request message (see Section 8.6) from the WTP.
>>        The AC responds with a Change State Event Response (see
>>        Section 8.7) message.
>> 
>>    Data Check to Run (m2): This state transition occurs when 
>> the WTP and
>>       AC enter their normal state of operation.
>> 
>>      WTP: The WTP enters this state when it receives a successful
>>        data channel keep-alive packet. It sends a Change State Event
>>        Request message (see Section 8.6).
>> 
>>      AC:  This state transition occurs when the AC receives the Change
>>        State Event Request message (see Section 8.6) from the WTP.
>>        The AC responds with a Change State Event Response (see
>>        Section 8.7) message.
>> 
>> [...]
>> 
>> 3.4 Data Channel Keep-alive
>> 
>>      Data channel keep alive packets are generated by the WTP 
>> and sent to
>>      the AC over the data channel UDP ports. These keep-alives MUST be
>>      generated by the WTP when a NAT device is discovered 
>> between the WTP
>>      and the AC. They serve the purpose of keeping the state active in
>>      the NAT device in the absence of no station data 
>> traffic. They are
>>      also used by the AC to tie the data channel to the 
>> appropriate WTP
>>      as they include the session ID in the payload (see 
>> Section 4.4.32).
>> 
>>      Data channel keep-alive packets need not be sent if a 
>> NAT device is
>>      not discovered.
>> 
>>      The WTP generates data channel keep-alive packets on a periodic
>>      basis. The AC, upon receipt of a data channel keep-alive packet,
>>      replies with its own keep-alive. When the AC receives 
>> the first data
>>      channel keep-alive packet it learns the data channel source and
>>      destination IP and UDP ports associated with the WTP and opens up
>>      the data channel accordingly.
>> 
>> [...]
>> 
>> 4.1 CAPWAP Header
>> 
>>          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
>>         
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>         |Version|   RID   |  HLEN   |  WBID   |T|F|L|W|M|K|   
>> Flags     |
>>         
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>         |          Fragment ID          |     Frag Offset     
>>     |Rsvd |
>>         
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> [...]
>> 
>>         K: The 'Keep-alive' K bit indicates the packet is a 
>> data channel
>>            keep-alive packet. The contents of the packet is 
>> the Session
>>            ID used in the Join Request (see Sections 4.4.32 and 6.1).
>>            This packet is used to map the data channel to the control
>>            channel for the specified session ID. The K bit 
>> must never be
>>            set for data packets containing user data nor may user data
>>            packets include the session ID.
>> [...]
>> 
>> 4.2.1 CAPWAP Data Channel Keep-alive Messages
>> 
>>     Data channel keep-alive packets have the following format:
>> 
>>         +------------------------------------------------------+
>>         | IP Header | UDP Header | CAPWAP Header | Session ID  |
>>         +------------------------------------------------------+
>> 
>>     CAPWAP Header fields are set as follows:
>> 
>>     RID:             0
>>     HLEN:            2
>>     WBID:            0
>>     T, F, L, W, M:   0
>>     K:               1
>>     Fragment ID:     0
>>     Fragment Offset: 0
>> 
>> [...]
>> 
>> 4.5.12 DataChannelKeepAlive
>> 
>>      The minimum time, in seconds, between sending data channel
>>      keep-alive packets to the AC with which the WTP has joined.
>> 
>>      Default: 30
>> 
>> 4.5.13 DataChannelDeadInterval
>> 
>>      The minimum time, in seconds, a WTP MUST wait without having
>>      received data channel keep-alive packets before the 
>> destination for
>>      the data channel keep-alive packets may be considered 
>> dead. Must be
>>      no less than 2*DataChannelKeepAlive seconds and no 
>> greater that 240
>>      seconds.
>> 
>>      Default: 60
>> 
>> [...]
>> 
>> 6.2 Join Response
>> 
>> [...]
>> 
>>     The following message element MUST be included in the 
>> Join Response
>>     message.
>> 
>>     o  AC Descriptor, see Section 4.4.1
>> 
>>     o  Result Code, see Section 4.4.31
>> 
>> 
>> _________________________________________________________________
>> To unsubscribe or modify your subscription options, please visit:
>> http://lists.frascone.com/mailman/listinfo/capwap
>> 
>> Archives: http://lists.frascone.com/pipermail/capwap
>> 
>_________________________________________________________________
>To unsubscribe or modify your subscription options, please visit:
>http://lists.frascone.com/mailman/listinfo/capwap
>
>Archives: http://lists.frascone.com/pipermail/capwap

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap