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

From: Darren <[email-masked]>
Date: Wed, 25 Jan 2006 10:35:11 -0700

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