Subject: RE: [Capwap] Issue 50: Increase maximum number of BSSs

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 2 May 2006 13:36:14 -0700

The number of BSSID supported is already in "IEEE 802.11 WTP WLAN Radio
Configuration".
 
That said, you are correct that the issue name is incorrect. However,
the issue raised is incorrect as the does exist a way for the WTP to
provide this info to the AC.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Dorothy Stanley [mailto:[email-masked]] 
	Sent: Tuesday, May 02, 2006 11:26 AM
	To: Jim Murphy
	Cc: capwap
	Subject: Re: [Capwap] Issue 50: Increase maximum number of BSSs

	All,
	 
	Looking at the original Issue 50 text:

	> Page 34, Section 5.1.3. LWAPP seems to assume that WLAN 
	> radios will support
	> 16 BSS's per Radio. It would be better not assume that every 
	> WTP supports 16 radios and add a field to indicate the number 
	> of virtual networks per radio.
	At one point, the sheer number of beacons will saturate the air
waves,
	so we need to pick a maximum. What number do we want?
	I think the issue name does not match the comment.
	It's not clear that the commenter is asking for more than 16
BSSIDs, but rather notes that the full
	16 are assumed to be supported at the WTP.  What if the WTP only
supports 4? There is no way currently
	for the WTP to communicate this to the AP. Section 5.1.3 is the
WTP Radio information message element.
	One solution would be to add a "Number of BSSIDs supported"
field to that message element.
	Another solution would be to add a new IEEE 802.11 message
element, to indicate the number of
	BSSIDs supported, and include that new message element in the
appropriate messages. I suggest the 
	later, to keep BSSIDs in the .11 binding definition. And,
separately, keep the max at 16 BSSIDs.

	Dorothy

	On 5/1/06, Jim Murphy <[email-masked]> wrote: 

		It seems that the limit of 16 BSSIDs is primarily
motivated
		by this WLAN/Status field in the data header. Perhaps
the WLAN/Status 
		field should be a broadcast domain identifier (a .1q tag
or VLANID).
		WTPs should then be told of the VLANID to
BSSID/broadcast-key mapping
		via control plane messages and replicate packets
accordingly.
		
		If a VLANID is used in place of this bitmap, the
protocol will scale 
		better. With the current proposal, I am concerned about
WTPs that have
		many radios or offer multiple VLANs per BSSID.
		
		Thanks,
		
		Jim
		
		Pat Calhoun (pacalhou) wrote:
		>
		> I would recommend that we reject this issue. 16 BSSIDs
is a large 
		> number, and the overhead in generating 16 or more
beacons outweighs the
		> usefullness in advertising that many networks.
		>
		> Pat Calhoun
		> CTO, Wireless Networking Business Unit
		> Cisco Systems 
		>
_________________________________________________________________
		> To unsubscribe or modify your subscription options,
please visit:
		> http://lists.frascone.com/mailman/listinfo/capwap 
		>
		> Archives: http://lists.frascone.com/pipermail/capwap

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

_________________________________________________________________
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: Wed, 3 May 2006 07:08:08 -0700

Agreed that

 However, the IEEE 802.11 WTP WLAN Radio Configuration, as currently
specified is "used by the AC to configure a radio on the WTP", though
the message element bindings indicate inclusion of the message element in
e.g. Config Request - coming from the WTP.

Suggest that we modify the text in -00 section 11.9.1, "IEEE WTP WLAN Radio
Configuration" to indicate that the message element is also used to
by the WTP to notify the AC of the number of BSSIDs the radio is capable of
supporting, when the message element is included in the
Configure Request (now Configure Status) message.

Dorothy

On 5/2/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
> That said, you are correct that the issue name is incorrect. However, the
> issue raised is incorrect as the does exist a way for the WTP to provide
> this info to the AC.
>
>
> Pat Calhoun
>  ------------------------------
> *From:* Dorothy Stanley [mailto:[email-masked]]
> *Sent:* Tuesday, May 02, 2006 11:26 AM
> *To:* Jim Murphy
> *Cc:* capwap
> *Subject:* Re: [Capwap] Issue 50: Increase maximum number of BSSs
>
>  All,
>
> At one point, the sheer number of beacons will saturate the air waves,
> It's not clear that the commenter is asking for more than 16 BSSIDs, but
> rather notes that the full
> 16 are assumed to be supported at the WTP.  What if the WTP only supports
> 4? There is no way currently
> for the WTP to communicate this to the AP. Section 5.1.3 is the WTP Radio
> information message element.
> One solution would be to add a "Number of BSSIDs supported" field to that
> message element.
> Another solution would be to add a new IEEE 802.11 message element, to
> indicate the number of
> BSSIDs supported, and include that new message element in the appropriate
> messages. I suggest the
> > It seems that the limit of 16 BSSIDs is primarily motivated
> > by this WLAN/Status field in the data header. Perhaps the WLAN/Status
> > field should be a broadcast domain identifier (a .1q tag or VLANID).
> > WTPs should then be told of the VLANID to BSSID/broadcast-key mapping
> > via control plane messages and replicate packets accordingly.
> >
> > If a VLANID is used in place of this bitmap, the protocol will scale
> > better. With the current proposal, I am concerned about WTPs that have
> > > I would recommend that we reject this issue. 16 BSSIDs is a large
> > > number, and the overhead in generating 16 or more beacons outweighs
> > the