Subject: [Capwap] FSM issues

From: "Yong Zhang" <[email-masked]>
Date: Thu, 3 Jul 2008 11:48:07 -0700

1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State
Transitions, although it is said in CAPWAP/DTLS interface chapter.

2. Join REQ need to be send at here.

   DTLS Connect to Join (d):  This transition occurs when the DTLS
      Session is successfully established.

      WTP:  This state transition occurs when the WTP receives the
         DTLSEstablished notification (see Section 2.3.2.2), indicating
         that the DTLS session was successfully established.  When this
         notification is received, the FailedDTLSSessionCount counter is
         set to zero.

3.
Data Check to DTLS Teardown (n):  This transition occurs when the WTP
      does not complete the Data Check exchange.

      WTP:  This state transition occurs if the WTP does not receive the
         Change State Event Response message before a CAPWAP
         transmission timeout occurs.

    Does the above need to be change to something like  RetransmitCount
  counter has reached the MaxRetransmit variable? Since we do not use
transmission timeout timer.

4.   Run to Run (q): AC

Clear Config Response:  The AC receives a Clear Configuration
            Response message from the WTP (see Section 8.9).

Need to add Clear Configuration REQ send.

5. Run to DTLS Teardown (p) maybe need to add echo failure case.

         "transitions to this state if the underlying reliable
         transport's RetransmitCount counter has reached the
         MaxRetransmit variable (see Section 4.7)."

This can cover WTP, but not AC.

Yong
_________________________________________________________________
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: Thu, 3 Jul 2008 13:22:23 -0700

I have created issue 139 to track these issues.

> 1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State
Transitions, although it is said in CAPWAP/DTLS interface 
> chapter.
Yes, you are correct. The description for the StartDTLS command is clear
that the WaitDTLS timer needs to be started, but it would be worth
including this in the state transition description, as all of the other
timers are also included in that section.

<text>
   Idle to DTLS Setup (3):  This transition occurs to establish a 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
         establishment with the 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.
</text>

>         notification is received, the FailedDTLSSessionCount counter
is
Yes, this was a strange omission - an obvious thing to do, but it needs
to be very clear.

<text>

         set to zero.  The WTP enters the Join state by transmiting the
         Join Request to the AC.
</text>

transmission timeout timer.
Yes, good point. I am including the same text we have in other state
transitions.

<text>

      WTP:  This state transition occurs if the WTP does not receive the
         Change State Event Response message before a CAPWAP
         retransmission timeout occurs.  The WTP also transitions to
         this state if the underlying reliable transport's
         RetransmitCount counter has reached the MaxRetransmit variable
         (see Section 4.7).
</text>

> Need to add Clear Configuration REQ send.
I'm not sure that I understand what you are saying. This event occurs
when the response is received. The Request was sent some time ago, hence
why the response was received. The receive of the Clear Config Request
is handled in the WTP section, and is present already.

> This can cover WTP, but not AC.
The echo would cause a retransmission timeout, which makes use of the
RetransmitCount counter. I guess I'm not sure that I understand the
issue you are trying to raise. Both the WTP and the AC can transmit
requests, so it is possible that either side timeouts, forcing this
state transition.

PatC

-----Original Message-----
From: Yong Zhang [mailto:[email-masked]] 
Sent: Thursday, July 03, 2008 11:48 AM
To: [email-masked]
Subject: [Capwap] FSM issues

1. waitDTLS is not started in the 2.3.1 CAPWAP Proto State Transitions,
although it is said in CAPWAP/DTLS interface chapter.

3.

4.   Run to Run (q): AC

Yong

---

From: "Yong Zhang" <[email-masked]>
Date: Thu, 3 Jul 2008 13:40:52 -0700

> is handled in the WTP section, and is present already.

Refer to other messages description in AC RUN state: Ac need to send
out the REQ, and AC need to receive RESP.
Just WTP clear Config Response also has the problem.

> requests, so it is possible that either side timeouts, forcing this

I only see the WTP sends REQ, and AC recvs RESP.  Where is it said that AC
also sends ECHO REQ?

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 7 Jul 2008 04:21:03 -0700

4. Run to Run. I now understand the point you are trying to make. The
text for Clear Configuration Request/Response is not consistent with the
other commands in this section. I am proposing the following changes,
which does not change any behavior, but only creates more consistency in
the text:

<text>
   Run to Run (q):  This is the normal state of operation.

      WTP:  This is the WTP's normal state of operation.  There are many
         events that result this state transition:
[...]
         Clear Config Request:  The WTP receives a Clear Configuration
            Request message (see Section 8.8) and MUST generate a
            corresponding Clear Configuration Response message (see
            Section 8.9).  The WTP MUST reset its configuration back to
            manufacturer defaults.
[...]
      AC:  This is the AC's normal state of operation:
[...]
         Clear Config Response:  The AC sends a Clear Configuration
            Request message (see Section 8.8) to the WTP to clear its
            configuration.  The AC receives a Clear Configuration
            Response message from the WTP (see Section 8.9).
</text>

5. Unfortunately, I'm still not understanding the issue you are trying
to raise. I am not claiming that the AC sends echo requests, I am simply
stating that requests (in general) can be transmitted by either the WTP
or the AC, while certain requests may have restrictions which are
clearly documented in the spec. So regardless of whether a request is an
echo request, or any other request, the retransmission, and subsequent
timeout, is the same. Therefore there is no need to add a specific
clause for echo requests timing out.

PatC
-----Original Message-----
From: Yong Zhang [mailto:[email-masked]] 
Sent: Thursday, July 03, 2008 1:41 PM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] FSM issues

> when the response is received. The Request was sent some time ago, 
> hence why the response was received. The receive of the Clear Config 
> Request is handled in the WTP section, and is present already.

Refer to other messages description in AC RUN state: Ac need to send out
the REQ, and AC need to receive RESP.
Just WTP clear Config Response also has the problem.

> requests, so it is possible that either side timeouts, forcing this 

I only see the WTP sends REQ, and AC recvs RESP.  Where is it said that
AC also sends ECHO REQ?

On Thu, Jul 3, 2008 at 1:22 PM, Pat Calhoun (pacalhou)
<[email-masked]> wrote:
> Yes, you are correct. The description for the StartDTLS command is 
> clear that the WaitDTLS timer needs to be started, but it would be 
> worth including this in the state transition description, as all of 
> the other timers are also included in that section.
>
> <text>
> Yes, this was a strange omission - an obvious thing to do, but it 
> needs to be very clear.
>
> <text>
> when the response is received. The Request was sent some time ago, 
> hence why the response was received. The receive of the Clear Config 
> Request is handled in the WTP section, and is present already.
>

---

From: "Yong Zhang" <[email-masked]>
Date: Mon, 7 Jul 2008 09:48:55 -0700

I want to say for 5 is that:

Only WTP sends echo request. So if the WTP is dead,  the AC will not
be able to receive the
echo req, and this will trigger a failure event in AC side after some
time. We need to add this
event to FSM.

Since AC does not send the req, " the retransmission, and subsequent
timeout, ..." will not
be used.

Yong

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 7 Jul 2008 14:32:29 -0700

Ah, I see. Yes, this does need to be mentioned, thanks for pointing that
out. The issue being raised here is that the Echo Request is used by a
WTP to keep its session alive with the AC. However, if the AC doesn't
receive an Echo Request in a certain amount of time, it needs to
consider the WTP dead (this text is already covered in section 7.2). 

Note that this does not break interoperability with -10. The older spec
was ambiguous in how the AC would timeout a WTP, and I suspect that most
people at least implemented what's being described below. The change is
specifically around being clear when the EchoInterval is set/reset in
the actual FSM. It was mentioned already in the description of the Echo
Request and Echo Response messages, but it does need to also be
mentioned in the FSM. 

The only new change is the mention of the EchoInterval timer being reset
on the WTP when it transmits a request to the AC while in the Run state.
Similarly, the AC resets its own EchoInterval timer when it receives a
request from the WTP. This language is necessary in order to fulfill the
language from section 4.5:

<existing text>
4.5.  CAPWAP Control Messages
[...]
   CAPWAP control messages sent from the WTP to the AC indicate that the
   WTP is operational, providing an implicit keep-alive mechanism for
   the WTP.  The Control Channel Management Echo Request and Echo
   Response messages provide an explicit keep-alive mechanism when other
   CAPWAP control messages are not exchanged.
</existing text>

Here is the new proposed text. Note that the text in section 4.6.14 is
only the mention of how the EchoInterval is set on the AC. No other
changes are made:

<text>

      WTP:  This is the WTP's normal state of operation.  The WTP resets
         its EchoInterval timer whenever it transmits a request to the
         AC.  There are many events that result this state transition:
[...]
         Echo Request:  The WTP sends an Echo Request message
            (Section 7.1) or receives the corresponding Echo Response
            message, (see Section 7.2) from the AC.  When the WTP
            receives the Echo Response, it resets its EchoInterval timer
            (see Section 4.7.7).
[...]
      AC:  This is the AC's normal state of operation.  Note that the
         receipt of any Request from the WTP causes the AC to reset its
         EchoInterval timer (see Section 4.7.7).
[...]
         Echo Request:  The AC receives an Echo Request message (see
            Section 7.1), to which it MUST respond with an Echo Response
            message(see Section 7.2).

   Run to DTLS Teardown (p):  This state transition occurs when an error
      has occurred in the DTLS stack, causing the DTLS session to be
      torn down.
[...]
      AC:  The AC enters this state when it receives one of the
         following DTLS notifications: DTLSAborted,
         DTLSReassemblyFailure or DTLSPeerDisconnect (see
         Section 2.3.2.2).  The WTP MAY tear down the DTLS session if it
         receives frequent DTLSDecapFailure notifications.  The AC
         transitions to this state if the underlying reliable
         transport's RetransmitCount counter has reached the
         MaxRetransmit variable (see Section 4.7).  This state
         transition also occurs when the AC's EchoInterval timer expires
         (see Section 4.7.7).

4.6.14.  CAPWAP Timers

   The CAPWAP Timers message element is used by an AC to configure
   CAPWAP timers on a WTP.

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Discovery   | Echo Request  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]
   Echo Request:   The number of seconds between WTP Echo Request CAPWAP
      messages.  This value is used to configure the EchoInterval timer
      (see Section 4.7.7).  The AC sets its EchoInterval timer to this
      value, plus the maximum retransmission time as described in
      Section 4.5.3.
</text>

PatC

-----Original Message-----
From: Yong Zhang [mailto:[email-masked]] 
Sent: Monday, July 07, 2008 9:49 AM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] FSM issues

Only WTP sends echo request. So if the WTP is dead,  the AC will not be
able to receive the echo req, and this will trigger a failure event in
AC side after some time. We need to add this event to FSM.

Since AC does not send the req, " the retransmission, and subsequent
timeout, ..." will not be used.

Yong

On Mon, Jul 7, 2008 at 4:21 AM, Pat Calhoun (pacalhou)
<[email-masked]> wrote:
> text for Clear Configuration Request/Response is not consistent with 
> the other commands in this section. I am proposing the following 
> changes, which does not change any behavior, but only creates more 
> consistency in the text:
>
> <text>

> to raise. I am not claiming that the AC sends echo requests, I am 
> simply stating that requests (in general) can be transmitted by either

> the WTP or the AC, while certain requests may have restrictions which 
> are clearly documented in the spec. So regardless of whether a request

> is an echo request, or any other request, the retransmission, and 
> subsequent timeout, is the same. Therefore there is no need to add a 
> specific clause for echo requests timing out.
>
> PatC

> I only see the WTP sends REQ, and AC recvs RESP.  Where is it said 
> that AC also sends ECHO REQ?
>
>

---

From: "Yong Zhang" <[email-masked]>
Date: Mon, 7 Jul 2008 18:48:54 -0700

This is OK for me.

Yong

>
> On Mon, Jul 7, 2008 at 2:32 PM, Pat Calhoun (pacalhou)