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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 6 Jun 2006 10:15:59 -0700

Recall that folks asked for 802.3 tunneling as optional in local MAC.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Tuesday, June 06, 2006 9:17 AM
	To: Pat Calhoun (pacalhou)
	Cc: capwap
	Subject: Re: [Capwap] Proposed Rsolution Issue 81: Minor edits
and questionsCAPWAP Protocol specification

	Pat,
	
	2. How would a WTP communicate that it is capable of providing
local bridging services to the AC?
	
	 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: 

		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