Subject: Re: [Capwap] Proposed Rsolution Issue 81: Minor edits and questionsCAPWAP Protocol specification

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 5 Jun 2006 17:27:28 -0700

Dorothy,
 
My comments (using your numbering below).
1. ok with change
2. How would a WTP communicate that it is capable of providing local
bridging services to the AC?
3. ok with change

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Thursday, May 25, 2006 12:28 PM
	To: capwap
	Subject: [Capwap] Proposed Rsolution Issue 81: Minor edits and
questionsCAPWAP Protocol specification

	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

---

From: "Dorothy Stanley" <[email-masked]>
Date: Tue, 6 Jun 2006 09:16:56 -0700

Pat,

 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.

What does "the local bridging function" mean? Based on the above (removed)
definition, local bridging applies only
to local-MAC cases, and "allows the WTP to perform the
bridging function". This sounds like what any local-MAC WTP would already
do, and
if so, it's not clear that an indication other than "local-MAC" provided in
section 4.4.38,
" WTP MAC Type" is needed.

Or, is a different meaning intended?

Thanks,

Dorothy

On 6/5/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
>  ------------------------------
> *From:* Dorothy Stanley [mailto:[email-masked]]
> *Sent:* Thursday, May 25, 2006 12:28 PM
> *To:* capwap
> *Subject:* [Capwap] Proposed Rsolution Issue 81: Minor edits and
> ----------------------------------------------------------------------------------
>
> Issue 81:
>
> If a Discovery Response .... equal to SilentInterval before sending further
> If a Discovery Response .... equal to SilentInterval before returning to the
> What do the frames look like -- do not understand what is sent or received.
>
>
> 1. Page 33, Section 5.1 is the Discovery Request Message definition
>
>    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
> in the Discover state whle determining which AC to send the Join Request
> message to, see the description of state (b), Discovery to Discovery.
>    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  |
>      +-+-+-+-+-+-+-+-+
>
>    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
>       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
>       4 - Native Bridging:  Native Bridging requires the WTP and AC to
>          encapsulate all user payloads as native wireless frames, as
>       7 - All:  The WTP is capable of supporting all frame encapsulation
>          types.
>
> To:
>
>    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  |
>      +-+-+-+-+-+-+-+-+
>
>    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
>       2 - Native Encapsulation:  Native Bridging requires the WTP and AC
> to
>          encapsulate all user payloads as native wireless frames, as
>       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

---

From: "Dorothy Stanley" <[email-masked]>
Date: Tue, 13 Jun 2006 16:29:30 -0700

Pat,

Ok, I suggest that we re-name the information element then, to
"Tunnel Mode", which seems to more accurately describe all modes in the
field, rather than Frame Type (-00) and (Encapsulation Type) (-01), and
which matches the language used in the IEEE 802.11 Add WLAN message element
The proposed text is below.

One question though. When local MAC/Local bridging is selected, what
encapsulation
is used for transport of the 802.11 Association and Action Frames from the
WTP to/from
the AC. It looks like that encapsulation is not yet specified. Are 2 modes
indicated  - local bridging and 802.3 or local bridging and native wireless,
with
the assumption that when local bridging is present, user data (vs 802.11control)
only is locally bridged?

Dorothy

So the suggested resolution for part 2 of issue 81 is:

Change from:

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

   Length:  1

To:

4.4.36.  WTP Tunnel Mode

   The WTP Tunnel Mode message element allows the WTP to
   communicate the 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 Tunnel Mode

   Length:  1

   Tunnel Mode:  The Tunnel Mode specifies the tunneling
      modes supported by the WTP.  The following values are supported:

      1 - Local Bridging:  When Local Bridging is used, the WTP does not
          tunnel user traffic to the AC; all user traffic is locally
bridged.
         This value MUST NOT be used when the WTP
         MAC Type is set to Split-MAC

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

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

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