Subject: [Capwap] Proposed Rsolution Issue 81: Minor edits and questions CAPWAP Protocol specification

From: "Dorothy Stanley" <[email-masked]>
Date: Thu, 25 May 2006 12:28:13 -0700

All,

The proposed resolution to Issue 81 is listed below.

Comments welcome.

Thanks,

Dorothy
----------------------------------------------------------------------------------

Issue 81:

Very Readable -- some minor comments

Page 33 -- Section 5.1 -- 5th paragraph

If a Discovery Response .... equal to SilentInterval before sending further
Discovery Request messages.

change to

If a Discovery Response .... equal to SilentInterval before returning to the
ide stand and sending further Discovery Request messages.

Section 5.1.5 WTP Frame Type -- Page 37 - Local Bridging

What do the frames look like -- do not understand what is sent or received.

Page 51 -- Top of Page -- Secton 7.3.2

cause repeated twice -- delete 1st reference

1. Page 33, Section 5.1 is the Discovery Request Message definition

The proposed change is to the following text:

   If a Discovery Response message is not received after sending the
   maximum number of Discovery Request messages, the WTP enters the
   Sulking state and MUST wait for an interval equal to SilentInterval
   before sending further Discovery Request messages.

Proposed resolution: In the -01 state machine, the WTP remains
in the Discover state whle determining which AC to send the Join Request
message to, see the description of state (b), Discovery to Discovery.
Reject the proposed change.

2. Section 5.1.4, WTP Frame Type is now section 4.4.36,
WTP Frame Encapsulation Type, copied below. It is unclear
why local bridging is listed as a frame type/eccapsulation type.

Recommended change:

Change from:

4.4.36.  WTP Frame Encapsulation Type

   The WTP Frame EncapsultationType message element allows the WTP to
   communicate the encapsulation type, or tunneling modes of operation
   which it supports to the AC.  A WTP that advertises support for all
   types allows the AC to select which type will be used, based on its
   local policy.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |Frame Enc Type  |
     +-+-+-+-+-+-+-+-+

   Type:  36 for WTP Frame Encapsulation Type

   Length:  1

   Frame Encapsulation Type:  The Frame type specifies the encapsulation
      modes supported by the WTP.  The following values are supported:

      1 - Local Bridging:  Local Bridging allows the WTP to perform the
         bridging function.  This value MUST NOT be used when the WTP
         MAC Type is set to Split-MAC.

      2 - 802.3 Bridging:  802.3 Bridging requires the WTP and AC to
         encapsulate all user payload as native IEEE 802.3 frames (see
         Section 4.2).  This value MUST NOT be used when the WTP MAC
         Type is set to Split-MAC.

      4 - Native Bridging:  Native Bridging requires the WTP and AC to
         encapsulate all user payloads as native wireless frames, as
         defined by the wireless binding (see Section 4.2).

      7 - All:  The WTP is capable of supporting all frame encapsulation
         types.

To:

4.4.36.  WTP Frame Encapsulation Type

   The WTP Frame EncapsultationType message element allows the WTP to
   communicate the encapsulation type, or tunneling modes of operation
   which it supports to the AC.  A WTP that advertises support for all
   types allows the AC to select which type will be used, based on its
   local policy.

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |Frame Enc Type  |
     +-+-+-+-+-+-+-+-+

   Type:  36 for WTP Frame Encapsulation Type

   Length:  1

   Frame Encapsulation Type:  The Frame type specifies the encapsulation
      modes supported by the WTP.  The following values are supported:

      1 - 802.3 Encapsulation:  802.3 Bridging requires the WTP and AC to
         encapsulate all user payload as native IEEE 802.3 frames (see
         Section 4.2).  This value MUST NOT be used when the WTP MAC
         Type is set to Split-MAC.

      2 - Native Encapsulation:  Native Bridging requires the WTP and AC to
         encapsulate all user payloads as native wireless frames, as
         defined by the wireless binding (see Section 4.2).

      3 - All:  The WTP is capable of supporting both frame encapsulation
         types.

3. Change State Event, now 4.4.11 - the first "case" reference, (duplicate
text) has been deleted in draft -01.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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