Subject: RE: [Capwap] Re: Data plane and control plane separation in SplitMAC

From: "Yang, Lily L" <[email-masked]>
Date: Fri, 13 Aug 2004 13:13:08 -0700

I also think it makes more sense to arrive at a single protocol for data
forwarding. It doesn't mean CAPWAP has to reinvent the wheel to come up
with yet another tunneling protocol -- existing protocol can be reused
for that purpose. But for interoperability, we need to agree on one
eventually.
So the relevant discussion is to understand the requirements for data
forwarding.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bob O'Hara
Sent: Friday, August 13, 2004 12:59 PM
To: [email-masked]
Subject: RE: [Capwap] Re: Data plane and control plane separation in
SplitMAC

I agree that for a complete solution, we cannot ignore the need for a
data forwarding protocol.  But for control and provisioning, not for
operation, that problem can be separated from the initial protocol
design.  

What we might consider in the protocol design is negotiating the data
forwarding protocol.  I do not favor negotiation of that protocol as the
final solution.  It leads to too many options in a multivendor situation
and will likely provide less interoperability rather than more.  When
the question arises, I would prefer we had the hard discussions to
arrive at a single protocol to be used for data forwarding.

 -Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Partha Narasimhan
Sent: Thursday, August 12, 2004 1:19 PM
To: Lily L Yang
Cc: Wijnen, Bert (Bert); Shankar Narayanaswamy;
[email-masked]; [email-masked]
Subject: RE: [Capwap] Re: Data plane and control plane separation in
SplitMAC

The set of AP functions is split across the WTP and the AC in the
split-MAC and, arguably to a lesser extent, in the local MAC
architectures. As a result, the AP, in these architectures, is no longer
a physical entity, but one that potentially spans a L3 boundary. The
handling of data frames (and some mgmt frames in the split-MAC arch)
within an AP could involve transferring it over a L3 network from the
WTP to the AC or vice-versa. If these two end-points are from multiple
different vendors, then there needs to be an agreement on the mode of
this transfer. Hence, we cannot ignore this problem in defining a CAPWAP
protocol.
Thanks
partha

On Thu, 2004-08-12 at 10:42, Yang, Lily L wrote:
> To examine our options of architecture assumptions, let me first put
our
> my definition of data plane and control plane just to make sure we
start
> from the same page:
> 
> To me, 802.11 data plane means the dath path travelled by the native
> 802.11 data frames while 802.11 control plane means the data path
> between 802.11 STA and the 802.11-awared control end point.  
> 
> For both Local and Split MAC, that 802.11-awared control point is AC.
So
> both architecture has the same control path: STA->WTP->AC. The
> difference is how that control messages are implemented between WTP
and
> AC: Split MAC simply tunneled the 802.11 management frames, while
Local
> MAC translated them into some other non-802.11 forms. Another
(implied)
> difference is that Split MAC largely relies on the AC to respond to
> those management frames from STA, while Local MAC relies on WTP to
> respond, but allow AC to be informed of such events as well. So the
> timing constraint may be more relaxed for local MAC.
> 
> The question is on the data path. Here is my understanding so far:
> In Local MAC, the data path is between STA and WTP. From WTP, it can
be
> switched or routed locally, entirely bypassing AC.  For Split MAC, My
> impression has been that the data path is between STA and WTP and AC,
> because it seems that Split MAC vendors tunnel ALL 802.11 data back to
> AC, even though I don't see why it has to be that way. Just from the
> recent discussion, some have hinted that even Split MAC can allow data
> path terminate at WTP and be "locally" switched without involving AC.
Is
> this true? Can anyone confirm more explicitly and elaborate this for
me?
> 
> 
> To summarize:
> Common control path: STA->WTP->AC. (but control messages between
> WTP<->AC are done diffrently)
> Local MAC data path: STA->WTP.
> Split MAC data path: STA->WTP->AC or STA->WTP (This needs to be
> clarified).
> 
> My hunch is that CAPWAP protocol would have to allow the flexibility
in
> datapath, for either architecture (Split or Local). So in that case,
it
> doesn't really matter if it is Split or Local, it should allow
datapath
> to be configurable any way. In that sense, I agree with what Shankar
was
> saying here. This seems also suggest that YES, we can cleanly separate
> data plane and control plane here. But that doesn't mean any
discussion
> around data plane is out of scope -- because guess what? Why do we
need
> the control plane at the first place? To control and configure the
data
> plane!
> 
> So understanding what data plane needs would drive our discussion for
> the control plane and CAPWAP.
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Wijnen, Bert (Bert)
> > Sent: Thursday, August 12, 2004 2:30 AM
> > To: Shankar Narayanaswamy; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [Capwap] Re: Data plane and control plane 
> > separation in Split MAC
> > 
> > > -----Original Message-----
> > > From: Shankar Narayanaswamy [mailto:[email-masked]]
> > > Sent: donderdag 12 augustus 2004 05:13
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: [Capwap] Re: Data plane and control plane 
> > separation in Split 
> > > MAC
> > > 
> > > 
> > > The parameters by which the data plane communicates such as 
> > > authentication/security info, destination switch (if any) for data

> > > frames, etc, are communicated by the control plane. Hence 
> > the need for 
> > > some architectural assumptions regarding the data plane even if
the 
> > > focus is on the control plane.
> > > 
> > > Or at least a decision on the data plane architectures to be 
> > > supported.
> > > 
> > So... to me that sounds that we may potentially do an IMPLIED 
> > agreement on the architecture for data plane, based on the 
> > capabilities we define in the standards track control and 
> > provisioning protocol.
> > 
> > That would be fine with me. But we should NOT get bogged down 
> > in that data plane stuff, or at least that to me seems to be 
> > the wrong focus.
> > 
> > Bert
> > > -s
> > > 
> > > [email-masked] wrote:
> > > > Good point.  Can we have the volunteers that submitted
> > > architectures for the taxonomy draft weigh in on this issue?   
> > > > 
> > > > Also another point to consider is that we don't have to
> > > implement *every* AP function in the first release of the CAPWAP 
> > > protocol.  One of our charter goals is to start with
> > > the minimal set of functionality needed to provide control.   
> > > We have a "desirable" category where we can put objectives 
> > that can be 
> > > met with a later release or extension.
> > > > 
> > > > Dorothy
> > > > 
> > > >>-----Original Message-----
> > > >>From: [email-masked] 
> > [mailto:[email-masked]]On
> > > >>Behalf Of ext Yang, Lily L
> > > >>Sent: Tuesday, August 10, 2004 6:13 PM
> > > >>To: Sudhanshu Jain; Shehzad Merchant; Shankar 
> > Narayanaswamy; Abhijit 
> > > >>Choudhury
> > > >>Cc: [email-masked]
> > > >>Subject: RE: [Capwap] So many architectures, so little time... -

> > > >>take 2
> > > >>
> > > >>
> > > >>The question in my mind is: Can data plane and control plane be 
> > > >>cleanly separated for Split MAC? I know it is feasible for Local
> > > MAC, but not
> > > >>sure about Split MAC. 
> > > >>Any insight?
> > > >>
> > > >>-----Original Message-----
> > > >>From: [email-masked]
> > > [mailto:[email-masked]] On
> > > >>Behalf Of Sudhanshu Jain
> > > >>Sent: Tuesday, August 10, 2004 11:55 AM
> > > >>To: Shehzad Merchant; Shankar Narayanaswamy; Abhijit Choudhury
> > > >>Cc: [email-masked]
> > > >>Subject: RE: [Capwap] So many architectures, so little time... -

> > > >>take 2
> > > >>
> > > >>I fully agree with Shehzad. We need to separate the 
> > control and data 
> > > >>plane. Control plane should provide the framework to use one of 
> > > >>several tunneling protocol.
> > > >>
> > > >>On data plane, if we need to define a new layer2/layer3 level 
> > > >>tunneling protocol, it should be separate work from 
> > control protocol 
> > > >>work.
> > > >>
> > > >>-Suds
> > > >>
> > > >>
> > > >>-----Original Message-----
> > > >>From: [email-masked]
> > > [mailto:[email-masked]] On
> > > >>Behalf Of Shehzad Merchant
> > > >>Sent: Tuesday, August 10, 2004 11:13 AM
> > > >>To: Shankar Narayanaswamy; Abhijit Choudhury
> > > >>Cc: [email-masked]
> > > >>Subject: RE: [Capwap] So many architectures, so little time... -

> > > >>take 2
> > > >>
> > > >>Additionally, for data tunneling one needs a lightweight 
> > mechanism 
> > > >>that may not necessarily have the same requirements as that for 
> > > >>control and management. For example, one would want to limit the

> > > >>tunneling and processing overhead on data packets to a minimum. 
> > > >>Control and management may be more tolerant of 
> > > >>tunneling/security/etc. overhead.
> > > >>Besides, there are
> > > >>plenty of standards in place for data tunneling. We may
> > > potentially be
> > > >>able
> > > >>to leverage off that work itself without having to invent
> > > yet another
> > > >>tunneling mechanism for data. 
> > > >>
> > > >>-S
> > > >>
> > > >>
> > > >>-----Original Message-----
> > > >>From: [email-masked]
> > > [mailto:[email-masked]] On
> > > >>Behalf
> > > >>Of Shankar Narayanaswamy
> > > >>Sent: Tuesday, August 10, 2004 10:30 AM
> > > >>To: Abhijit Choudhury
> > > >>Cc: [email-masked]
> > > >>Subject: Re: [Capwap] So many architectures, so little time... -

> > > >>take 2
> > > >>
> > > >>On the first point: not necessarily. If data packets are
> > > encapsulated
> > > >>802.11 data frames, then there is no need to protect them
> > > on the wire
> > > >>any
> > > >>more than they were encrypted over the air.
> > > >>
> > > >>But control and management packets will need protection
> > > over the wired
> > > >>network and therefore possibly a different tunneling protocol.
> > > >>
> > > >>On the second point (standard way of packet exchange): yes!
> > > >>
> > > >>-s
> > > >>
> > > >>Abhijit Choudhury wrote:
> > > >>
> > > >>>The same tunneling protocol that moves control and
> > > >>
> > > >>management packets
> > > >>
> > > >>>from the WTP to the AC should be used to tunnel data
> > > >>
> > > >>packets as well.
> > > >>
> > > >>
> > > >>>We would specify message exchanges to do control, 
> > provisioning and 
> > > >>>capability advertisement between WTPs and the AC.  But 
> > all of this 
> > > >>>would be within the unified CAPWAP protocol that moves 
> > all packets 
> > > >>>including data between the WTP and AC.  Vendors currently
> > > >>
> > > >>use LWAPP,
> > > >>
> > > >>>GRE, IP and some proprietary encapsulations to achieve 
> > this.  This 
> > > >>>group would come up with a "standard" way of doing this
exchange.
> > > >>>
> > > >>>At least that was my understanding....
> > > >>>
> > > >>>Regards,
> > > >>>Abhijit
> > > >>>
> > > >>>-----Original Mssage-----
> > > >>>From: [email-masked]
> > > >>
> > > >>[mailto:[email-masked]] On
> > > >>
> > > >>>Behalf Of Wijnen, Bert (Bert)
> > > >>>Sent: Monday, August 09, 2004 6:14 AM
> > > >>>To: 'Yang, Lily L'; Burbank, Jack L.; Victor Lin; Bob O'Hara; 
> > > >>>[email-masked]
> > > >>>Subject: RE: [Capwap] So many architectures, so little
> > > >>
> > > >>time... - take
> > > >>
> > > >>>2
> > > >>>
> > > >>>
> > > >>>Not sure who is confused... probably me...
> > > >>>
> > > >>>My understanding was/is that IF we do re-charter for CAPWAP
> > > >>
> > > >>protocol
> > > >>
> > > >>>work, that it is then a NM protocol for "Control and
> > > >>
> > > >>Provisioning" and
> > > >>
> > > >>
> > > >>>not any of the related stuff that moves the data from WTP to
AC.
> > > >>>
> > > >>>Is everybody in agreement with that understanding.
> > > >>>
> > > >>>Thanks,
> > > >>>Bert
> > > >>>
> > > >>>
> > > >>>
> > > >>>>-----Original Message-----
> > > >>>>From: Yang, Lily L [mailto:[email-masked]]
> > > >>>>Sent: maandag 9 augustus 2004 08:14
> > > >>>>To: Burbank, Jack L.; Victor Lin ; Bob O'Hara ;
> > > [email-masked]
> > > >>>>Subject: RE: [Capwap] So many architectures, so little
> > > >>>
> > > >>time... - take
> > > >>
> > > >>>>2
> > > >>>>
> > > >>>>
> > > >>>>I think setting the re-charter scope to develop a single
> > > >>>
> > > >>protocol that
> > > >>
> > > >>>
> > > >>>>allows interoperability between Local and Split MAC is a
> > > reasonable
> > > >>>>tradeoff:
> > > >>>>We exclude remote MAC because the constraint it imposes is
very 
> > > >>>>different from the rest and the benefit of including it is
very 
> > > >>>>little. But Local and Split MAC are reasonably close and
> > > hence the
> > > >>>>effort may be incremental only.
> > > >>>>As many people noted, as of today, there is no single clear
> > > >>>
> > > >>definition
> > > >>
> > > >>
> > > >>>>of what "Local MAC" and "Split MAC" really means yet. Each
> > > >>>
> > > >>vendor has
> > > >>
> > > >>>>different definitions and some debate needs to happen so
> > > >>>
> > > >>that the WG
> > > >>
> > > >>>>can reach consensus on what exactly that means, and 
> > what kinds of 
> > > >>>>flexibility we want to retain within each class of
> > > >>>
> > > >>architecture, and
> > > >>
> > > >>>>what kind of differences we can to resolve and agree up
> > > front. That
> > > >>>>should also be part of the work items for the new WG --
> > > >>>
> > > >>such agreement
> > > >>
> > > >>
> > > >>>>on the details for each architecture must be documented
> > > >>>
> > > >>somewhere, if
> > > >>
> > > >>>>not separately, then as part of the Protocol document.
> > > >>>>
> > > >>>>-----Original Message-----
> > > >>>>From: [email-masked]
> > > >>>
> > > >>[mailto:[email-masked]] On
> > > >>
> > > >>>>Behalf Of Burbank, Jack L.
> > > >>>>Sent: Thursday, August 05, 2004 12:14 PM
> > > >>>>To: 'Victor Lin '; 'Bob O'Hara '; [email-masked] '
> > > >>>>Subject: RE: [Capwap] So many architectures, so little
> > > >>>
> > > >>time... - take
> > > >>
> > > >>>>2
> > > >>>>
> > > >>>>I think that interoperability between different
> > > >>>
> > > >>architectures should
> > > >>
> > > >>>>be a requirement, if not the key requirement.  As was
mentioned 
> > > >>>>yesterday, a goal of the IEEE is that they maintain
> > > flexibility in
> > > >>>>terms of how products and architectures are implemented.  I
> > > >>>
> > > >>think we
> > > >>
> > > >>>>shouldn't do anything that is contrary to that goal (or
> > > at least we
> > > >>>>should minimize the impact).  I think that the goal of
> > > >>>
> > > >>CAPWAP should
> > > >>
> > > >>>>be to retain this type of flexibility by designing a
> > > >>>
> > > >>protocol that can
> > > >>
> > > >>
> > > >>>>maintain this implementation flexibility but enable
> > > >>>
> > > >>interoperability
> > > >>
> > > >>>>between the various architecture implementations (that
> > > after all is
> > > >>>>the key problem with the deployment of these various
> > > >>>
> > > >>architectures -
> > > >>
> > > >>>>lack of interoperability).  IMO, if we don't design for 
> > > >>>>interoperability between the basic architecture types, it
> > > >>>
> > > >>is debatable
> > > >>
> > > >>
> > > >>>>if something useful would have been accomplished.
> > > >>>>
> > > >>>>Jack Burbank
> > > >>>>
> > > >>>>-----Original Message-----
> > > >>>>From: [email-masked]
> > > >>>>To: Bob O'Hara; [email-masked]
> > > >>>>Sent: 8/5/2004 2:46 PM
> > > >>>>Subject: RE: [Capwap] So many architectures, so little
> > > >>>
> > > >>time... - take
> > > >>
> > > >>>>2
> > > >>>>
> > > >>>>I agree that we can design a protocol and implement the
> > > >>>
> > > >>product that
> > > >>
> > > >>>>works all architectures. I think the question to CAPWAP is:
> > > >>>>
> > > >>>>Should we make it a requirement in CAPWAP protocol to achieve 
> > > >>>>interoperability between different architectures?
> > > >>>>
> > > >>>>It is definitely doable, but I'm not sure if that is the
> > > >>>
> > > >>right thing
> > > >>
> > > >>>>to do..
> > > >>>>
> > > >>>>Victor
> > > >>>>
> > > >>>>-----Original Message-----
> > > >>>>From: [email-masked]
> > > >>>
> > > >>[mailto:[email-masked]] On
> > > >>
> > > >>>>Behalf Of Bob O'Hara
> > > >>>>Sent: Thursday, August 05, 2004 11:43 AM
> > > >>>>To: [email-masked]
> > > >>>>Subject: RE: [Capwap] So many architectures, so little
> > > >>>
> > > >>time... - take
> > > >>
> > > >>>>2
> > > >>>>
> > > >>>>I think that interoperability will depend on two things.
> > > >>>>First, it will
> > > >>>>depend on how we define the protocol and the flexibility
> > > >>>
> > > >>for supported
> > > >>
> > > >>
> > > >>>>architectures it incorporates.  Second, it will depend on what

> > > >>>>manufacturers implement, i.e., the flexibility they build
> > > >>>
> > > >>into their
> > > >>
> > > >>>>products.
> > > >>>>
> > > >>>>I believe that it is possible to design the protocol for
> > > >>>
> > > >>the required
> > > >>
> > > >>>>flexibility.  I know it is possible to implement a
> > > product with the
> > > >>>>required flexibility.
> > > >>>>
> > > >>>>-Bob O'Hara
> > > >>>>
> > > >>>>
> > > >>>>-----Original Message-----
> > > >>>>From: [email-masked]
> > > >>>
> > > >>[mailto:[email-masked]] On
> > > >>
> > > >>>>Behalf Of Abhijit Choudhury
> > > >>>>Sent: Thursday, August 05, 2004 11:32 AM
> > > >>>>To: James Kempf; Shehzad Merchant; [email-masked]
> > > >>>>Cc: [email-masked]; [email-masked]; 
> > [email-masked]; 
> > > >>>>[email-masked]; Inderpreet Singh
> > > >>>>Subject: RE: [Capwap] So many architectures, so little
> > > >>>
> > > >>time... - take
> > > >>
> > > >>>>2
> > > >>>>
> > > >>>>
> > > >>>>It may be possible to achieve such interoperability within the

> > > >>>>split-MAC family or within the local-MAC family.  It
> > > would sbe very
> > > >>>>hard to achieve that between local and split MAC families.
> > > >>>>
> > > >>>>For example, if vendor X's WTP terminates 802.11 ctrl/mgmt
> > > >>>
> > > >>packets and
> > > >>
> > > >>>
> > > >>>>vendor Y's AC expects the 802.11 mgmt packets to come to
> > > >>>
> > > >>it, there's
> > > >>
> > > >>>>no way you can be interoperable.
> > > >>>>
> > > >>>>Or are we planning to specify ONE architecture ?
> > > >>>>The last thing IETF should do is mandate an implementation.
> > > >>>>
> > > >>>>I think a modest and reasonable goal is to come up with a
> > > protocol
> > > >>>>that allows sufficient flexbility so that vendors with
splitMAC 
> > > >>>>architectures can transfer most of the information they
> > > care about
> > > >>>>between the WTP and AC.
> > > >>>>
> > > >>>>Just my $0.02 ...
> > > >>>>
> > > >>>>
> > > >>>>Abhijit Choudhury
> > > >>>>
> > > >>>>
> > > >>>>-----Original Message-----
> > > >>>>From: [email-masked]
> > > >>>
> > > >>[mailto:[email-masked]] On
> > > >>
> > > >>>>Behalf Of James Kempf
> > > >>>>Sent: Wednesday, August 04, 2004 3:29 PM
> > > >>>>To: Shehzad Merchant; [email-masked]
> > > >>>>Cc: [email-masked]; [email-masked]; 
> > [email-masked]; 
> > > >>>>[email-masked]; Inderpreet Singh
> > > >>>>Subject: Re: [Capwap] So many architectures, so little
> > > >>>
> > > >>time... - take
> > > >>
> > > >>>>2
> > > >>>>
> > > >>>>
> > > >>>>As a potential customer, let me put it concretely. I want
> > > >>>
> > > >>to be able
> > > >>
> > > >>>>to buy my access points from Vendor X and my switch from
> > > >>>
> > > >>Vendor Y and
> > > >>
> > > >>>>plug the two together and have them work without any
> > > configuration. 
> > > >>>>Also, I'd like to be able to buy switches from Vendor Y and
> > > >>>
> > > >>Vendor Z
> > > >>
> > > >>>>and be able to plug them into my network at various
> > > places and have
> > > >>>>them interoperate.
> > > >>>>
> > > >>>>           jak
> > > >>>>
> > > >>>>
> > > >>>>----- Original Message -----
> > > >>>>From: "Shehzad Merchant" <[email-masked]>
> > > >>>>To: <[email-masked]>
> > > >>>>Cc: <[email-masked]>; <[email-masked]>; 
> > > >>>><[email-masked]>; <[email-masked]>;
> > > "Inderpreet
> > > >>>>Singh"
> > > >>>><[email-masked]>
> > > >>>>Sent: Wednesday, August 04, 2004 3:19 PM
> > > >>>>Subject: RE: [Capwap] So many architectures, so little
> > > >>>
> > > >>time... - take
> > > >>
> > > >>>>2
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>I think the implementation variations even with the
> > > split MAC may
> > > >>>>>cover a broad spectrum. As such its important to clearly
> > > >>>>
> > > >>articulate
> > > >>
> > > >>>>>what aspects
> > > >>>>
> > > >>>>of
> > > >>>>
> > > >>>>
> > > >>>>>interoperability we are targetting. Is it truly just 
> > > >>>>>control/management or is it interoperability between
disparate 
> > > >>>>>implementations of the split MAC, i.e. mix and match
> > > >>>>
> > > >>>>operation of WTP
> > > >>>>
> > > >>>>
> > > >>>>>and ACs of all variants within this category.
> > > >>>>>
> > > >>>>>I suspect for the latter we may have to arrive at some
> > > >>>>
> > > >>consensus on
> > > >>
> > > >>>>>what particular implementations we are targeting
> > > >>>>
> > > >>>>interoperability for.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>If so, ultimately this problem statement could become
> > > part of the
> > > >>>>>charter.
> > > >>>>>
> > > >>>>>-Shehzad
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>-----Original Message-----
> > > >>>>>From: [email-masked]
> > > >>>>
> > > >>>>[mailto:[email-masked]] On Behalf
> > > >>>>
> > > >>>>
> > > >>>>>Of [email-masked]
> > > >>>>>Sent: Wednesday, August 04, 2004 11:53 AM
> > > >>>>>To: [email-masked]; [email-masked]
> > > >>>>>Cc: [email-masked]; [email-masked]; 
> > [email-masked]
> > > >>>>>Subject: RE: [Capwap] So many architectures, so little
> > > >>>>
> > > >>>>time... - take
> > > >>>>
> > > >>>>
> > > >>>>>2
> > > >>>>>
> > > >>>>>I believe this is the consensus, to scope the charter to
> > > >>>>
> > > >>>>Centralized
> > > >>>>
> > > >>>>
> > > >>>>>Architecture and LocalMAC and Split MAC.
> > > >>>>>
> > > >>>>>I'll update the charter with this change after the CAPWAP
> > > >>>>
> > > >>>>WG Mtg. If
> > > >>>>
> > > >>>>
> > > >>>>>there is resistance to this idea, please post to the list.
> > > >>>>>
> > > >>>>>Regards
> > > >>>>>Dorothy
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>>-----Original Message-----
> > > >>>>>>From: [email-masked]
> > > >>>>>
> > > >>>>[mailto:[email-masked]]On
> > > >>>>
> > > >>>>
> > > >>>>>>Behalf Of ext Inderpreet Singh
> > > >>>>>>Sent: Tuesday, August 03, 2004 9:40 PM
> > > >>>>>>To: [email-masked]
> > > >>>>>>Cc: [email-masked]; [email-masked]; Kessens David 
> > > >>>>>>(Nokia-NET/MtView); Gellert Dorothy (Nokia-ES/MtView)
> > > >>>>>>Subject: RE: [Capwap] So many architectures, so little
> > > time... -
> > > >>>>>>take 2
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>The issue(s) at hand and my opinions are:
> > > >>>>>>
> > > >>>>>>1. Do we explicitly state in the re-charter which
> > > >>>>>
> > > >>>>architecture the
> > > >>>>
> > > >>>>
> > > >>>>>>WG should consider? I think yes.  I propose Centralized
> > > >>>>>
> > > >>>>architecture
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>>only. Autonomous and Distributed should be out of scope
> > > >>>>>
> > > >>>>based on the
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>>same reasons as per prior postings.
> > > >>>>>>
> > > >>>>>>2. Within Centralized do we focus on all three sub
> > > >>>>>
> > > >>>>architectures or
> > > >>>>
> > > >>>>
> > > >>>>>>a subset? Remote MAC should be excluded because if I am not 
> > > >>>>>>mistaken, the connectivity constraint between the WTP and
> > > >>>>>
> > > >>>>the AC is
> > > >>>>
> > > >>>>
> > > >>>>>>"direct connect".
> > > >>>>>>That being the case and that no IP layer is involved, 
> > it doesn't
> > > >>>>>
> > > >>>>seem
> > > >>>>
> > > >>>>
> > > >>>>>>clear what kind of protocol would help with
> > > interoperability. I am
> > > >>>>>
> > > >>>>>>concerned about the impact, dependencies and
> > > interaction with the
> > > >>>>>>recently constituted IEEE Study group on AP
> > > >>>>>
> > > >>>>functionality on the
> > > >>>>
> > > >>>>
> > > >>>>>>Split MAC architectures.  Furthermore, there are some
> > > >>>>>
> > > >>>>pretty drastic
> > > >>>>
> > > >>>>
> > > >>>>>>differences on how the vendors have chosen to split the
> > > >>>>>
> > > >>>>mac.  Those
> > > >>>>
> > > >>>>
> > > >>>>>>differences will need to be worked out before designing a
> > > >>>>>
> > > >>>>protocol.
> > > >>>>
> > > >>>>
> > > >>>>>>So, if the low hanging fruit strategy (as James 
> > suggested) for 
> > > >>>>>>protocol development and progress is the way to go,
> > > then I think
> > > >>>>>>prioritizing on a protocol for Local MAC is a no brainer.
> > > >>>>>
> > > >>>>So as far
> > > >>>>
> > > >>>>
> > > >>>>>>as focus, I feel we should do Local and Split and in 
> > that order.
> > > >>>>>>
> > > >>>>>>3. This is not a re-chartering issue but is a 
> > response to Pat's 
> > > >>>>>>suggestion that a protocol that just sends the 802.11
> > > MAC frames
> > > >>>>>
> > > >>>>>>from the AP to the AC would work.  I think possibly, yes.
> > > >>>>>
> > > >>>>
> > > >>>>But again
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>>the complications of splitting the MAC in an
> > > >>>>>
> > > >>>>interoperable way will
> > > >>>>
> > > >>>>
> > > >>>>>>be an issue.  Also, you may note in the draft to which
> > > >>>>>
> > > >>>>you refer, we
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>>included a capabilities exchange phase.  I had thought of
> > > >>>>>
> > > >>>>including
> > > >>>>
> > > >>>>
> > > >>>>>>in the capability exchange such things as "AP supports
> > > Local MAC"
> > > >>>>>>and "AP supports Split MAC", but didn't put it in because
the 
> > > >>>>>>Taxonomy work was still in progress.  Now that it is
> > > pretty much
> > > >>>>>>done we could surely include that.  But again...let's 
> > recharter 
> > > >>>>>>first.
> > > >>>>>>
> > > >>>>>>Thanks.  Do people agree with 1 & 2?
> > > >>>>>>
> > > >>>>>>---
> > > >>>>>>Inderpreet Singh
> > > >>>>>>Chantry Networks
> > > >>>>>>[email-masked]
> > > >>>>>>Cell: 416-831-3705
> > > >>>>>>
> > > >>>>>>-----Original Message-----
> > > >>>>>>From: [email-masked]
> > > >>>>>
> > > >>>>[mailto:[email-masked]]
> > > >>>>
> > > >>>>
> > > >>>>>>On Behalf Of Pat R. Calhoun
> > > >>>>>>Sent: Tuesday, August 03, 2004 6:04 PM
> > > >>>>>>To: Yang, Lily L; James Kempf; [email-masked]; 
> > > >>>>>>[email-masked]
> > > >>>>>>Cc: [email-masked]; [email-masked]; 
> > [email-masked]
> > > >>>>>>Subject: [Capwap] So many architectures, so little
> > > >>>>>
> > > >>>>time... - take 2
> > > >>>>
> > > >>>>
> > > >>>>>>After reading Lily's response to Jim, I realize that I
> > > >>>>>
> > > >>>>fell down the
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>>same trap. Local MAC is also a centralized approach, 
> > and so my 
> > > >>>>>>previous response was not complete. I believe the real
> > > >>>>>
> > > >>>>question, in
> > > >>>>
> > > >>>>
> > > >>>>>>my mind, is whether we need to address either the Local
> > > >>>>>
> > > >>>>or the Split
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>>>MAC architecture.
> > > >>>>>>
> > > >>>>>>Just looking at the Architecture Consideration tables (7 and
> > > >>>>>>10) in the
> > > >>>>>>specification, the
> > > >>>>>>main difference (at a high level) between both approaches
> > > >>>>>
> > > >>>>is where
> > > >>>>
> > > >>>>
> > > >>>>>>the 802.11 management terminates. For Local MAC, it's
> > > in the WTP,
> > > >>>>>>while for SPlit MAC, it's in the AC.
> > > >>>>>>
> > > >>>>>>However, looking at table 8, most Local MAC approaches
> > > share STA
> > > >>>>>>state between both the WTP and the AC. So clearly 
> > there is some 
> > > >>>>>>signalling protocol between both the WTP and the AC.
> > > >>>>>>
> > > >>>>>>Looking at one example of a Local MAC protocol (see
> > > >>>>>>
> > > >>>>>
> > > 
> >
>>>http://www.ietf.org/internet-drafts/draft-singh-capwap-ctp-00.txt),
> > > >>>
> > > >>>
> > > >>>>>there is a protocol message
> > > >>>>>that corresponds for every 802.11 MAC management event. So
> > > >>>>
> > > >>when a STA
> > > >>
> > > >>
> > > >>>>>associates, the AP breaks the message apart and creates an
new 
> > > >>>>>protocol PDU, which contains components found in the 
> > association 
> > > >>>>>request. I suspect that most Local MAC approaches do
> > > >>>>
> > > >>something very
> > > >>
> > > >>>>>similar.
> > > >>>>>
> > > >>>>>So if a protocol simply tunnels the 802.11 MAC management
> > > >>>>
> > > >>frames from
> > > >>
> > > >>
> > > >>>>>the WTP to the AC, it allows supports both approaches. For
> > > >>>>
> > > >>Local MAC,
> > > >>
> > > >>
> > > >>>>>they get what they want via the 802.11 frame, and this
> > > also works
> > > >>>>>fine for Split MAC, which needs access to the MAC
> > > >>>>
> > > >>management frame. 
> > > >>
> > > >>>>>What would be required in such a protocol is a way for 
> > the AP to 
> > > >>>>>communicate whether it will be providing very specific
> > > functions -
> > > >>>>>basically a capabilities negotiation approach.
> > > >>>>>
> > > >>>>>So I do believe that there is a way to address both
> > > architectures
> > > >>>>>using a single protocol.
> > > >>>>>
> > > >>>>>Thoughts?
> > > >>>>>
> > > >>>>>PatC
> > > >>>>>
> > > >>>>>_______________________________________________
> > > >>>>>Capwap mailing list
> > > >>>>>[email-masked]
> > > >>>>
> > > >>http://mail.frascone.com/mailman/listinfo/capwap
> > > >>
> > > >>>>_______________________________________________
> > > >>>>Capwap mailing list
> > > >>>>[email-masked]
> > > http://mail.frascone.com/mailman/listinfo/capwap
> > > >>>>_______________________________________________
> > > >>>>Capwap mailing list
> > > >>>>[email-masked]
> > > http://mail.frascone.com/mailman/listinfo/capwap
> > > >>>
> > > >>>
> > > >>>
> > > >>>_______________________________________________
> > > >>>Capwap mailing list
> > > >>>[email-masked]
> > http://mail.frascone.com/mailman/listinfo/capwap
> > >>>_______________________________________________
> > >>>Capwap mailing list
> > >>>[email-masked] 
> > http://mail.frascone.com/mailman/listinfo/capwap
> > >>>_______________________________________________
> > >>>Capwap mailing list
> > >>>[email-masked] 
> > http://mail.frascone.com/mailman/listinfo/capwap
> > >>>_______________________________________________
> > >>>Capwap mailing list
> > >>>[email-masked] 
> > http://mail.frascone.com/mailman/listinfo/capwap
> > >>>_______________________________________________
> > >>>Capwap mailing list
> > >>>[email-masked] 
> > http://mail.frascone.com/mailman/listinfo/capwap
> > >>>_______________________________________________
> > >>>Capwap mailing list
> > >>>[email-masked] 
> > http://mail.frascone.com/mailman/listinfo/capwap
> > >>>_______________________________________________
> > >>>Capwap mailing list
> > >>>[email-masked] 
> > http://mail.frascone.com/mailman/listinfo/capwap
> > >>>_______________________________________________
> > >>>Capwap mailing list
> > >>>[email-masked]
> > >>>http://mail.frascone.com/mailman/listinfo/capwap
> > >>
> > >>
> > >>--
> > >>Shankar Narayanaswamy, Ph.D.
> > >>[email-masked]            Mobile: +1 650-387-4593
> > >>http://www.shankar.org          E-Fax: +1 253-498-8372
> > >>
> > >>_______________________________________________
> > >>Capwap mailing list
> > >>[email-masked]
> > >>http://mail.frascone.com/mailman/listinfo/capwap
> > >>_______________________________________________
> > >>Capwap mailing list
> > >>[email-masked]
> > >>http://mail.frascone.com/mailman/listinfo/capwap
> > >>_______________________________________________
> > >>Capwap mailing list
> > >>[email-masked]
> > >>http://mail.frascone.com/mailman/listinfo/capwap
> > >>_______________________________________________
> > >>Capwap mailing list
> > >>[email-masked]
> > >>http://mail.frascone.com/mailman/listinfo/capwap
> > > 
> > > 
> > 
> > 
> > --
> > Shankar Narayanaswamy, Ph.D.
> > [email-masked]            Mobile: +1 650-387-4593
> > http://www.shankar.org          E-Fax: +1 253-498-8372
> > 
> > _______________________________________________
> > Capwap mailing list
> > [email-masked]
> > http://mail.frascone.com/mailman/listinfo/capwap
> > _______________________________________________
> > Capwap mailing list
> > [email-masked]
> > http://mail.frascone.com/mailman/listinfo/capwap
> > 
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: Shankar Narayanaswamy <[email-masked]>
Date: Fri, 13 Aug 2004 13:41:36 -0700

A single protocol for data forwarding is a worthy goal. However that may be
suboptimal in some cases.

Consider where the entire WEP/TKIP/WPA data frame is encrypted/decrypted in the
AC. It would be unnecessary and unreasonably demanding to use SSL or some other
encrypted IP tunneling protocol between the WTP and the AC. Any simple IP-in-IP
protocol would suffice and allow the WTP to be more lightweight than would
otherwise be the case.

So we should aim for allowing a (very small) set of well-known, standard data
forwarding protocols to be negotiated over the control plane. The actual number
of protocols (and which ones) is something that we as a group will decide.

-s

---

From: Dan Harkins <[email-masked]>
Date: Fri, 13 Aug 2004 15:43:25 -0700

Unnecessary negotiation has been the bane of quite a few IETF protocols
(I will submit IKE-- RFC2409-- as a prime example because I know who's
responsible for it and he won't mind). Why can't the "set of well-known,
standard data forwarding protocols" have a single member? 

  Dan.

On Fri, 13 Aug 2004 13:41:36 PDT you wrote

---

From: Shankar Narayanaswamy <[email-masked]>
Date: Fri, 13 Aug 2004 17:36:35 -0700

Mainly because having a single member may seriously impinge on the 
flexibility of the system. For example, do we insist that everyone use 
SSL with 1024 bit keys or allow different key lengths?

Also, there is nothing magic about "1". However it often precludes "more 
than 1" if the system is not designed properly.

It is fair to start with a single "required" member to guarantee 
interoperability. Others could be "optional" and determined by technical 
and/or market need.

-s

---

From: Dan Harkins <[email-masked]>
Date: Fri, 13 Aug 2004 18:05:36 -0700

Oh no. There is something quite magic about "1". There is also a rule
that comes into play when designing protocols and it is ignored at one's
own risk:

	"There are three possible values: zero, one and infinity."

That rule as been shown to be true time and time again.

  Your SSL example does not apply as there is no negotiation necessary
to deal with keys of different lengths. If you can't design a protocol
that has a single way to tunnel packets then you're gonna need some
negotiation capability to select which method (and probably end up 
having to implement the entire set-- woo-hoo code bloat!) and while that
will allow you to design Yet Another Negotiation Protocol (tm) it's
an unnecessary interoperability problem. One mandatory and multiple
optional is a recipe for disaster. Been there; done that; got pilloried.

  Go ahead though. I reserve the right to say "ha ha told ya so" in a
couple of years.

  Dan.

On Fri, 13 Aug 2004 17:36:35 PDT you wrote
> >>forwarding protocols to be negotiated over the control plane. The actual nu
>mb
> >>er

---

From: "Srini" <[email-masked]>
Date: Fri, 20 Aug 2004 12:03:14 -0700

I also believe that having a single tunneling protocol is simple and provides better
interoperability among AC and WTPs. 

As you have indicated, it is important to come out with the requirements for 
data forwarding. 

Some of the requirements:
   - 802.3 or 802.11 (Based on whether it is Split AP or Split MAC) packets
      need to be forwarded to the AC from WTPs.
   - WTPs and AC can be connected either directly rechable (same physical
      network) or connected through intermediate routers.
   - WTP and AC are connected through insecure networks.
   - Quality of Service should not be compromized for data packets. 
   
IPinIP, IPSec, SSL alone can't be used to satisfy above requirements.
We require tunneling protocol which encapsulate Layer2 data (MAC frames) in
IP or UDP headers. TCP is not suitable as QoS may not be achieved. 
Wherever security is required, additional IPSec tunneling can be used to 
protect encapsulated traffic.

Since control traffic such as 802.1x traffic,  802.11x events (such as 
Associate, De_Associate, Re-associate and others) need to be sent with
reliability,  TCP based protocol can be used.

I feel that, two kinds of connections are required - TCP based for 
sending/receiving control traffic and  MAC(L2) over IP/UDP based encapsulation
for forwarding the data traffic. Optional IPSec can be used to protect
this traffic.

Paylaod formats of these protocols would be based on the  type of control traffic
is required to be sent/received between WTP and AC. 

Srini