Subject: RE: Multiple/Redundant AC's (was: Re: [Capwap] Additional Comment s on LWAPP)

From: Michael Montemurro <[email-masked]>
Date: Wed, 25 Jan 2006 12:40:28 -0500

My personal opinion on this one is that we have enough issues to resolve
with the AP-WTP protocol definition. I think AC-AC communications is
important. However I think we should table that issue for now.

Cheers,

	Mike

> -----Original Message-----
> From: Darren [mailto:[email-masked]] 
> Sent: January 25, 2006 12:35 PM
> To: David T. Perkins
> Cc: [email-masked]; [email-masked]
> Subject: Multiple/Redundant AC's (was: Re: [Capwap] 
> Additional Comments on LWAPP)
> 
> David,
> 
> I am in support for removing the AC address information element.
> 
> Regarding the big picture of multiple AC's, I agree with you 
> that this is a scope question.  Should this be a requirement or not?
> 
> >From my experience working with large customer deployments, it is a
> common requirement that there is some ability to utilize 
> multiple AC's.  First they want some kind of redundancy and 
> second there is load balancing.  I have worked with several 
> real campus deployments where there are over 500 WTP's (some 
> with 1,000's of WTP's and growing).  These environments are 
> deployed in a design that is very much like a Local-MAC with 
> 802.3 backhaul to an "AC-like" device. 
> Multiple AC-like devices are already in these networks.  
> Mitigating the AC as a single point of failure is a 
> requirement for them.  Load balancing of AC's (as cool as I 
> think this is) is only a requirement for the largest of 
> WLAN's I've seen and is merely nice to have for almost everyone else.
> 
> So I think it's very important to have this problem solved 
> one way or another.  There should be one solution and it 
> should be multi-vendor WTP <-> AC interoperable.
> 
> LWAPP/CAPWAP will work without explicit support for this and 
> there can be proprietary extensions (as suggested in LWAPP 
> 3.3.2) to solve the problem.  But those will not likely be 
> plug-and-play interoperable.
> 
> Is there any support for making support multiple AC discovery 
> mandatory?
> 
> -Darren Loher
> 
> 
> On 1/24/06, David T. Perkins <[email-masked]> wrote:
> > HI,
> >
> > Let's backup here to understand the big picture before 
> specifying the 
> > details.
> >
> > Currently, the CAPWAP architecture for which the protocol is being 
> > standardized consists of
> >  1) a collection of WTPs
> >  2) a single AC
> >  3) an L2 or L3 interconnection cloud between the WTPs
> >     and single AC
> >  4) a protocol between the single AC and each WTP that
> >     allows the AC to configure(provision), control,
> >     monitor, and potentially tunnel wireless client
> >     stattion data frames between an WTP and AC
> >
> > Thus, there is no concept of multiple ACs such as for 
> robustness using 
> > a "backup AC", or scaling with load balancing WTPs amoung a set of 
> > cooperating ACs.
> >
> > The LWAPP specification, unfortunately, has impurities that 
> suggests a 
> > richer architecture that contains multiple ACs.
> >
> > It seems to me that the WG needs to determine the scope of 
> version 1.0 
> > of the CAPWAP architecture and protocol.
> > If it is a single AC, then the impurities due to multiple 
> ACs should 
> > be removed. Otherwise, the architecture should be extended 
> to describe 
> > what features are to be addressed by multiple ACs. Note 
> that even in a 
> > single AC architecture, the protocol must cope with rogue ACs (and 
> > WTPs).
> >
> > On Tue, 24 Jan 2006, Darren wrote:
> > > Regarding 5.2.1 AC Address,  I think there could still be use for 
> > > this information.  As Philip started to point out, it's possible 
> > > that an AC might want to refer a WTP to a different 
> address than the 
> > > WTP first discovered.
> > >
> > > I suppose there are other ways to direct WTP's to discover 
> > > alternative AC's, such as via multiple DNS A records or 
> SRV records.  
> > > So perhaps the AC address is not really needed even for a sort of 
> > > redirection or load balancing.
> > >
> > > -Darren Loher
> > >
> > > On 1/20/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
> > > > > General Comment:  Radio ID's are limited to be between 0 and
> > > > > 7 inclusive.
> > > > > The definition of Radio ID in the fields should show this 
> > > > > limited range -- one byte allocated but only 8 values allowed.
> > > >
> > > > A previous comment of yours caught caused me to catch 
> this one already.
> > > > It will be fixed in the first rev.
> > > >
> > > > >
> > > > > Page 35 -- 5.2.1 AC address
> > > > > I do not understand this.  It is not useful with a layer 3 
> > > > > transport.  If using a layer 2 transport then I would 
> assume the 
> > > > > broadcast or multicast from the Discovery Message would have 
> > > > > been heard by any other AC's -- so rather than respond
> > > > > -- would it not be best to stay silent?
> > > >
> > > > I believe you are correct that this information element is not 
> > > > required for layer 3, and can be removed. I've added 
> this to tracker.
> > > >
> > > > >
> > > > > General Comment:  Is there a case where one has a simple 
> > > > > discovery agent running in dumb hardware -- its only 
> purpose is 
> > > > > to redirect the WTP to the real AC?  There seems to 
> be hints of 
> > > > > this possibility but it is not spelled out.
> > > >
> > > > There are many things one can do with the protocol, but 
> I think we 
> > > > should leave implementors determine what they can, and 
> cannot, do.
> > > >
> > > > Pat Calhoun
> > > > CTO, Wireless Networking Business Unit Cisco Systems
> >
> > 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
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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