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

From: Jim Murphy <[email-masked]>
Date: Thu, 04 Jan 2007 16:57:10 -0800

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 9 Jan 2007 10:27:21 -0800

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
> 
> 
> The first issue is the need for a keep-alive in the data 
> channel to ensure the maintenance of the NAT state.
> 
> 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
> -------------
>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 9 Jan 2007 10:55:36 -0800

oh, for simplicity sake, would you disagree if the Data Check state was
always used?

Pat Calhoun

> From: Pat Calhoun (pacalhou) 
> Sent: Tuesday, January 09, 2007 10:27 AM
> To: Jim Murphy; capwap
> 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
> > 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.
> 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.
> > 
> >    Data Check to Run (m2): This state transition occurs 
> when the WTP 
> > and
> >      Data channel keep alive packets are generated by the 
> WTP and sent 
> > to
> >      generated by the WTP when a NAT device is discovered 
> between the 
> > WTP
> >      Data channel keep-alive packets need not be sent if a 
> NAT device 
> > is
> >      not discovered.
> > 
> >      replies with its own keep-alive. When the AC receives 
> the first 
> > data
> >          0                   1                   2          
>          3
> >            channel for the specified session ID. The K bit 
> must never 
> > be
> >      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
> > 
> > [...]
> >

---

From: Jim Murphy <[email-masked]>
Date: Tue, 09 Jan 2007 11:04:06 -0800

I was thinking that the session ID could appear directly after the
CAPWAP header as a 64 bit field. Effectively the session ID is the
payload. However, if their is a requirement for extensibility in the
proposed data channel keep-alive message, I am not against adding
the control message format and either defining a new message type or
reusing echo request/response for this purpose.

Thanks,

Jim

Pat Calhoun (pacalhou) wrote:
>> between the WTP
>> NAT device is
>> the first data
>> must never be
>> destination for
>> dead. Must be
>> greater that 240

---

From: Jim Murphy <[email-masked]>
Date: Tue, 09 Jan 2007 11:12:16 -0800

Replying to both Pat and Scott:

I am not opposed to the data channel keep-alive being a MUST requirement
(not just for NAT).

With this modification, the Data Check state is always used and a
successful data channel keep-alive transaction must occur before moving
to the Run state. Therefore, Scott's requirement for keep-alives being
established prior to data transmission is met.

Thanks,

Jim

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 10 Jan 2007 06:41:16 -0800

Jim,

First, thanks for your proposed text. Based on the comments
on the list, I have made some tweaks, and am including what
I would propose for text. Please let me know if you are ok
with it.

Note that the state machine is based on the proposed text for issue
226.

2.3.  CAPWAP State Machine Definition
[...]
     /=================>=====================================\
     " /===============<=================================\   "
     " " /=============<=============================\   "   "
     " " " /===========<=========\                   "   "   "
     " " " "             n4,n5,n6"                 n8" n3"   v
     " " " "   +-----------+   +--------------+     +----------+
     " " " "   | DTLS Idle |   |  DTLS Setup  |     | DTLS Run |
     " " " "   +-----------+   +--------------+     +----------+
     " " " "   ^   "n1   ^c4    ^  ^         "n2   c3^  n7"  ^
     " " " "   "   "     "      "  "         "       "    "  "    DTLS
     "~"~"~"~~~"~~~"~~~~~"~~~~~~"~~"~~~~~~~~~"~~~~~~~"~~~~"~~"~~~~~~~~
     " " " "   "   "     \======"=="=======\ "  /====/    "  "  CAPWAP
     ^ v v v   "   "            "  "       " "  "         "  "
     " " " "   "   "    /=======/  "       " "  "         "  "
     " " " "   "   "    "          "       " "  "         "  "
     " " " "   "c1 v    "c2   d    "c2     " v  "         "  "
     " " " \=>+------------+   +------+   +------+        "  "
     " " "    |    Idle    |-->| Disc |   | Auth |        "  "
     " " \===>+------------+ a +------+   +------+        "  "
     " "      b|    ^           |d     /==================/  "
     " "       |    |      /----/      "   /-----------------"----\
     " "       v   f|      |           v  s|                 "c5  |
     " "      +---------+  |     r+----------+ t +------------+   |
     " "      | Sulking |<-/      |   Run    |-->|   Reset    |   |
     " "      +---------+         +----------+   +------------+   |
     " "                              ^         ^       ^         |
     " "        +------------+ q      |         |       |         |
     " "        | Data Check |--------/   /-----/       |         |
     " "        +------------+<-------\   |             |         |
     " "                             p|  k|          j  |         v
     " \======>+--------------+     +-----------+     +------------+
     "       c5|    Join      |---->| Configure |---->| Image Data |
     \=========+--------------+  g  +-----------+  h  +------------+

                 Figure 3: CAPWAP Integrated State Machine

2.3.1.  CAPWAP Protocol State Transitions
[...]
   Configure to Data Check (p):  This state transition occurs when the
      WTP and AC confirm the configuration.

      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.6), and
         transmits the Change State Event Request message (see
         Section 8.7).

      AC:  This state transition occurs when the AC receives the Change
         State Event Request message (see Section 8.7) from the WTP.
         The AC responds with a Change State Event Response (see
         Section 8.8) message.  The AC must start the
         NeighborDeadInterval timer (see Section 4.6).

   Data Check to Run (q):  This state transition occurs once the linkage
      between the control and data channels has occured, which causes
      the WTP and AC to enter their normal state of operation.

      WTP:  The WTP enters this state when it receives a successful
         Change State Event Response from the AC.  The WTP initiates the
         data channel, which MAY require the establishment of a DTLS
         session, starts the DataChannelKeepAlive timer (see
         Section 4.6) and transmits a Data Channel Keep Alive (see
         Section 4.3.1).  The WTP then starts the
         DataChannelDeadInterval timer (see Section 4.6).

      AC:  This state transition occurs when the AC receives the Data
         Channel Keep Alive (see Section 4.3.1), whose Session ID
         message element matches the one included by the WTP in the Join
         Request.  Note that if the AC's policy is to require the data
         channel to be encrypted, this process would also require the
         establishment of the data channel's DTLS session.  Upon
         receiving the Data Channel Keep Alive, the AC transmits its own
         Data Channel Keep Alive.

4.2.  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 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 (optional) Radio MAC Address                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            (optional) Wireless Specific Information           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Payload ....                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]
   K: The 'Keep-alive' K bit indicates the packet is a data channel
      keep-alive packet.  This packet is used to map the data channel to
      the control channel for the specified Session ID and to maintain
      freshness of the Data Channel.  The K bit MUST NOT be set for data
      packets containing user data.

4.3.1.  CAPWAP Data Keepalive

   The CAPWAP data keepalive is used to bind the CAPWAP control channel
   with the data channel.  The keep alive is also used to maintain
   freshness of the data channel, meaning ensuring the channel is still
   in functioning.  The CAPWAP Data Keepalive is transmitted by the WTP
   when the DataChannelKeepAlive timer expires.  When the CAPWAP Data
   Keepalive is transmitted, the WTP sets the DataChannelDeadInterval
   timer.

   All of the fields in the CAPWAP header, other than the HLEN and K
   bit, are set to zero upon transmission.  Upon receiving a CAPWAP Data
   Keepalive, the AC transmits a CAPWAP Data Keepalive message back to
   the WTP.  The contents of the CAPWAP message is assumed to be
   identical to the one received.

   Upon receiving a CAPWAP Data Keepalive, the WTP cancels the
   DataChannelDeadInterval timer and resets the DataChannelKeepAlive
   timer.  The CAPWAP Data Keepalive is retranmitted by the WTP in the
   same manner as the CAPWAP control messages.  If the
   DataChannelDeadInterval timer expires the WTP tears down the control
   DTLS session, as well as the data DTLS session if one existed.

   The CAPWAP Data Keepalive contains the following payload immediately
   following the CAPWAP Header (see Section 4.2)

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Msg Element Length     |      Msg Element [0..N] ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Element Length:   The Length field indicates the number of
      bytes following the CAPWAP Header.

   Message Element[0..N]:   The message element(s) carry the information
      pertinent to each of the CAPWAP Data Keepalive message.  The
      following message elements MUST be present in this CAPWAP message:

         Session ID, see Section 4.5.32

4.6.1.  DataChannelKeepAlive

   The minimum time, in seconds, between sending data channel keep-alive
   packets to the AC with which the WTP has joined.  The default value
   is 30 seconds.

4.6.2.  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: 5

Pat Calhoun

---

From: Jim Murphy <[email-masked]>
Date: Wed, 10 Jan 2007 09:24:29 -0800

Pat,

I am OK with this proposed text.

Thanks,

Jim

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 11 Jan 2007 08:28:19 -0800

Just wanted to note that the proposed text below was in reference to
issue 127.

Pat Calhoun

> Sent: Wednesday, January 10, 2007 6:41 AM
> To: Jim Murphy; capwap
> on the list, I have made some tweaks, and am including what I 
> would propose for text. Please let me know if you are ok with it.
> 
> Note that the state machine is based on the proposed text for 
> issue 226.
> 
> 2.3.1.  CAPWAP Protocol State Transitions [...]
>        |                        Payload ....                  
>          |
> keep-alive