Subject: [Capwap] Proposal for Discovery Clarification

From: "David T. Perkins" <[email-masked]>
Date: Wed, 24 Jan 2007 07:14:43 -0800 (PST)

HI,

I believe how discovery works in current CAPWAP is
not clearly specified. The following is a
proposed clarification.

-----------------------------------------
Discovery Model in CAPWAP
-------------------------

In CAPWAP, a WTP initiates the establishment of a DTLS session
with an AC. To do so, it must have the transport address of
an AC, which can be obtained via the following sources:
   1) from the WTP's configuration (and there can be
      multiple ordered values), which could be:
        a) an IPv4 network address with an optional UDP port
           (if the port is not specified, then the well known
            port is used to form the transport address)
        b) an IPv4 network address with an optional UDP port
           (if the port is not specified, then the well known
            port is used to form the transport address)
        c) a DNS fully qualified name
        d) an unqualified DSN name
   2) from DHCP (and there can be multiple ordered values,
       which could be in the format as specified in #1)
   3) from a response to a broadcast/multicast discovery
      request message (and there can be multiple values,
      with ordering determined by <to-be-specified>)
   4) from the previous connection to an AC (a single value)

Questions for CAPWAP
--------------------

1) When are each source of AC transport address used?

2) When is a discovery message first sent to an AC before
    initiation of a DTLS session, and when does a WTP skip
    sending a discovery message and just does the initiation
    of a DTLS session.

3) When is a discovery message sent to the broadcast/multicast
    network address?

4) When a discovery message is to be sent, and there are multiple
    AC addresses, is a discovery message sent to all AC addresses
    and done before trying to initiate a DTLS session. Or is
    discovery only sent to the first AC, and if a response received,
    then a DTLS session initiated.

5) If multiple discovery messages sent before initiation of
    DTLS session, and there are multiple discovery responses,
    how are these ordered?

6) What happens if DTLS initiation fails, or if a DTLS session
    is established and join fails(WTP gets no response or AC
    receives no request), or if join succeeds and the AC
    rejects the connection (sends a result code to the join)?

Answers in Current CAPWAP
-------------------------

I don't believe that current CAPWAP is sufficiently specified
to answer the above questions. (Can anyone see it differently
and provide the answers?)

Scenarios That Must Be Supported
--------------------------------
1) Brand new WTP with no configuration info
2) WTP that resets after image download done immediately
    after Join
3) WTP that resets after change of initial configuration
    after Join and before Run
4) WTP that has a configured AC and that AC responds to
    discover message
5) WTP that has configured AC and that AC either a) doesn't
    respond to discover message, b) fails during DTLS session
    establishment, c) establishes the DTLS session and fails
    the Join
6) A WTP that is reset from the Run state

Proposed Model
--------------

key terms:
cold boot - a WTP is power-cycled, or is rebooted to clear all
             transient state info
warm boot - a WTP that is reset and remembers the AC that it
             was previously connected to

Modified Operations
-------------------
1) Join - the response to a join request is under specified.
    As is, if join is to fail, the result code message element
    (4.4.31) is returned. Failure values 3-8 are well defined,
    but the result of failure value 1 is insufficiently defined.
    When this value is returned, then either or both of the
    IPv4 or IPv6 AC list message elements (4.4.2 or 4.4.3)
    must also be returned. The issue is what is the WTP
    to do with these lists.  (Note also, there are the
    two problems with the lists: 1) there should be one
    ordered list, not two 2) The lists have network addresses,
    and they should have transport addresses, 3) the list
    should allow DNS fully qualified and unqualified names.)
    I suggest that the behavior of a join with result code
    value 1 is an AC redirect. The list of the ACs returned
    should be merged into the AC candidate list in the
    following way:
       1) the ACs in the candidate list that connection
          has already been attempted (and failed) and are
          ignored in the referral list
       2) other ACs in the referral list are inserted
          in the candidate list at the place of the
          current AC
       3) ACs in the candidate list that come after the
          the current AC and are in the referral list
          are removed from the candidate list (so they are
          not twice in the candidate list)
    The referral list does not cause the configuration in
    the WTP to be modified.
2) Reset - the current definition of the Reset request specifies
    that it contain no message elements. Thus, there is no way
    to specify the image to use on the reboot or whether or not
    a cold or warm boot should occur.
    I suggest that the Reset request be modified so that it can
    optionally contain message separate elements to specify
    image for next boot, and cold/warm reboot.
3) Discover - the current definition of a Discover response does
    not have a way for the AC to indicate that it does not want
    the WTP to connect to it. Also, the current Discover response
    does not have a direct way for the AC to specify its preference
    for a WTP to connect to it.
    Thus, I suggest that the Discover response be modified so that it
    contains a message element to indicate that the AC preference
    for the WTP to connect to it, with a specific value that indicates
    that is does not want the WTP to connect to it.

Proposed Discovery Model
------------------------
A WTP reboots.

1) If it was a warm boot, then it has the transport
address of the AC to connect to. It does not send a
Discovery message, and initiates a DTLS session to the
the AC. If the DTLS session is established, and the Join
succeeds, then all done. Otherwise, it clears all transient
state info and starts the procedure for a cold boot.

2) If it was a cold boot, it creates an ordered list of
candidate AC addresses from the configuration. If the list
is empty, then it goes to step #3. It performs the
"Discover-Join" procedure, which is:
     It starts with the first in the list, and for each until
     it joins with an AC or reaches the end of the list, it does
     the following:
       a) sends a discover request
       b) if it does not get a response or gets a negative response,
          it proceeds with the next AC in the list
       c) after getting a response to the Discover request, the
          WTP initiates a DTLS session
       d) if the session can not be established, or a response
          is not received from a join, the WTP proceeds with the
          next AC in the list
       e) if the Join response is a referral, then the candidate
          AC list is updated and the WTP proceeds with the
          next AC in the list
       f) otherwise, have successfully joined with an AC, so all
          done with Boot.

3) The configured list is empty, or has entries and no join
    was successful. A new candidate list is constructed using
    info from DHCP and configured DNS name(s). If the list is
    not empty, then the "Discover-Join" procedure is performed.
    If it succeeds, then all done. Otherwise, perform #4.

4) Have not connected to an AC with configured or DHCP supplied
    values, so send Discovery request(s) to broadcast/multicast
    address(es). Build a list of candidate AC addresses.
    Order the list by the preference value specified by
    each AC. If the list is not empty, perform the "Discover-Join"
    procedure. If it succeeds, then all done. Otherwise,
    perform go to sulking state. (NOTE: would like time in
    sulking state to be exponentially back-off with truncation
    so that in a network with no AC available and "lots" of
    WTPs, that the amount of WTP broadcast traffic is minimized.)

I believe that the above proposal has the following properties:
1) It has minimal time for reconnect after WTP cold or warm
    reboot when the AC is available. (This is the most important
    attribute.)
2) It has good resiliency when failure occurs during connect.
3) It has determination in connecting to the same AC.
4) It recovers WTPs that have stored configuration when
    they are re-deployed without clearing their config
    into a new deployment environments.

-----------------------------------------
Regards,
/david t. perkins

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

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