Subject: [Capwap] New issue 256: Changes to DTLS Flow figure

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 16 Apr 2007 09:48:32 -0700

The old draft had a figure that exceeded the 74 character limit. In
cleaning up the figure, I ended up making the flow more consistent with
other flow diagrams in both specifications. Further, while making the
change, I have tried to make it clearer in the cases where multiple DTLS
packets can be aggregated into a single message.

The following is the new proposed text:
<proposed text>
2.2.  CAPWAP Session Establishment Overview

   This section describes the session establishment process message
   exchanges in the ideal case.  The annotated ladder diagram shows the
   AC on the 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 DTLS allows
   certain messages to be aggregated into a single frame, which is
   denoted via an asterix in the following figure.

           ============                         ============
               WTP                                   AC
           ============                         ============
            [----------- begin optional discovery ------------]

                           Discover Request
                 ------------------------------------>
                           Discover Response
                 <------------------------------------

            [----------- end optional discovery ------------]

                      (-- begin DTLS handshake --)

                             ClientHello
                 ------------------------------------>
                      HelloVerifyRequest (with cookie)
                 <------------------------------------

                        ClientHello (with cookie)
                 ------------------------------------>
                                ServerHello,
                                Certificate,
                                ServerHelloDone*
                 <------------------------------------

                (-- WTP callout for AC authorization --)

                        Certificate (optional),
                         ClientKeyExchange,
                     CertificateVerify (optional),
                         ChangeCipherSpec,
                              Finished*
                 ------------------------------------>

                (-- AC callout for WTP authorization --)

                            ChangeCipherSpec,
                                 Finished*
                 <------------------------------------

                (-- DTLS session is established now --)

                              Join Request
                 ------------------------------------>
                              Join Response
                 <------------------------------------

                  (-- assume image is up to date --)

                      Configuration Status Request
                 ------------------------------------>
                      Configuration Status Response
                 <------------------------------------

                        (-- enter RUN state --)

                                   :
                                   :

                              Echo Request
                 ------------------------------------>
                             Echo Response
                 <------------------------------------

                                   :
                                   :

                              Event Request
                 ------------------------------------>
                             Event Response
                 <------------------------------------

                                   :
                                   :
</proposed text>

Comments?

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

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

---

From: "Sudhanshu" <[email-masked]>
Date: Tue, 17 Apr 2007 15:35:58 -0700

Pat et. Al.

In case of local bridging, isn't the data channel should be optional?

But looks like we assume that data channel will always be present. What are
the benefits this data channel provide in case of local briding?

Or is it some oversight?

_Suds

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 20 Apr 2007 16:41:49 -0700

Because some of the 802.11 management frames need to be sent to the AC,
and this is done in the data channel.

PatC 

-----Original Message-----
From: Sudhanshu [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 3:36 PM
To: 'capwap'
Subject: [Capwap] Local Bridging

Pat et. Al.

But looks like we assume that data channel will always be present. What
are the benefits this data channel provide in case of local briding?

Or is it some oversight?

_Suds