Subject: RE: [Capwap] Data plane and control plane separation in Split MAC

From: Victor Lin <[email-masked]>
Date: Wed, 11 Aug 2004 08:48:41 -0700

I certain believe we can split control and data plane in split MAC protocol.
The big difference between split MAC and split AP are:

1. Split AP tunnel back 802.3 frames where split MAC tunnel back 802.11
frames to AC.
2. Split AP terminate 802.11 management frame on WTP but split MAC tunnel
back 802.11 management frames back to AC. Split will need some other
means/protocols to synchronize control information between AC and WTP.

Both architectures have clean separation between control and data plane, but
they all use different method to handle control and data plane communication
between AC and WTP.

If the goal of the CAPWAP is to support interoperability between two
architectures, we certainly need to address those differences.

Victor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Tuesday, August 10, 2004 6:59 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Capwap] Data plane and control plane separation in Split MAC

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
> 
_______________________________________________
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: <[email-masked]>
Date: Thu, 12 Aug 2004 15:49:06 -0700

Hi Lily-

In response to the Local MAC tunneling, my understanding is that that user data can be switched off of the WTP in a normal GRE or IPinIP tunnel or a number of other standard routing options, but it doesn't make sense in terms of what we are trying to accomplish in the first place, as you indicate. 

In an earlier email Bert and Shankar agreed that the CAPWAP scope of Local and Split MAC may have implications on the choice of data plane architectures.   I agree with this statement in the Charter focus/scope, and to refine the requirement in the Objectives/Criteria document.

If anyone has any objections, please comment.

Dorothy

> From: ext Yang, Lily L [mailto:[email-masked]]
> Sent: Thursday, August 12, 2004 10:43 AM
> To: Wijnen, Bert (Bert); Shankar Narayanaswamy; Gellert Dorothy
> (Nokia-ES/MtView)
> Cc: [email-masked]
> Subject: RE: [Capwap] Re: Data plane and control plane separation in
> Split MAC
> 
> 
> 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.
> 
> > [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
> > 
> > > 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
> > > > 
> time... - 
> > > >>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?
> > > >>
> time... - 
> > > >>plane. Control plane should provide the framework to use one of 
> > > >>several tunneling protocol.
> > > >>
> > > >>tunneling protocol, it should be separate work from 
> > control protocol 
> > > >>work.
> > > >>
> > > >>-Suds
> > > >>
> > > >>
> time... - 
> > 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
> time... - 
> > > >>>>[mailto:[email-masked]] On Behalf
> > > >>>>
> > > >>>>
> > > time... -

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Fri, 13 Aug 2004 11:02:42 -0600

Dataplane and control plane does not (have to) equate to 802.11 data
frames and non-data frames verbatim.

Specifically - 802.1X frame authentication traffic is distinguished at
AP(WTP) as controlled port traffic i.e., as an AP function (, if you
will)
It can be classified as a (CAPWAP) control plane traffic and mapped as
such.
It is also true the 'real' control port function may end up residing in
some arch. in AC. But a state-representation of it can (& will) still be
present in WTP - if for nothing other than blocking data traffic until
authentication. I suppose that is true for the protected 'tunneled'
authentication part as well.

This is a classic example needing to distinguish between identifying
WLAN AP functions (not so much where they reside) but how they may
interface & be controlled - beyond 802.11 MAC layer services.

Thus, the reference would be more appropriately to CAPWAP 'data-plane'
(it exists and is impacted - but not the focus of CAPWAP protocol) and
control-plane - if you will - and how AP flows map to each.

Comments?

The case that Behcet is alluding to is more interesting. If I understand
correctly where a 'non-AP' function is involved by way of user
authentication that is not a standard recognizable as a MAC/link-layer
function/interface; it is a higher layer function served by a higher
layer service (at AC presumably) - past the 802.1X authentication. It
looks clearly out of scope. I may have understood the issue wrongly - I
could not spot the related text in the referred CTP draft.

Regards,
-mani
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Saravanan Govindan
Sent: Thursday, August 12, 2004 10:26 PM
To: 'Yang, Lily L'; 'Wijnen, Bert (Bert)'; 'Shankar Narayanaswamy';
[email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Re: Data plane and control plane separation in
Split MAC

Hi Lily,

Good analysis of the different paths. Some input on the data & control
plane
separation; when using 802.1X, authentication information is
encapsulated in
802.11 data frames. In such cases, we have 802.1X control information
embedded in the data plane. So, it may not be possible to make a clean
separation between data and control planes. Some sort of snooping will
have
to be done on the data frames to check if they are carrying
authentication
(control) information. This situtaion could be included as one that
needs to
be addressed. 

Cheers

Saravanan

> first put our my definition of data plane and control plane 
> just to make sure we start from the same page:
> 
> 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.  
> 
> 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
> 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.
> 
> 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).
> 
> 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.
>

---

From: "Bob O'Hara" <[email-masked]>
Date: Fri, 13 Aug 2004 12:47:30 -0700

Lily,

Your description of the data and control paths for the split MAC
architecture are accurate for the Airespace system, where the data path
is terminated in the AC (STA->WTP->AC).

 -Bob

-----Original Message-----
Behalf Of Yang, Lily L
To: Wijnen, Bert (Bert); Shankar Narayanaswamy;

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:

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:

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!

> > authentication/security info, destination switch (if any) for data 
> > some architectural assumptions regarding the data plane even if the 
> > >>control and management. For example, one would want to limit the 
> > >>Subject: Re: [Capwap] So many architectures, so little time... - 
> > >>take 2
> > >>

---

From: Shehzad Merchant <[email-masked]>
Date: Fri, 13 Aug 2004 15:13:48 -0700

I do agree that the data forwarding protocol work can have some degree of
independence from the initial control/provisioning work. However, would the
data protocol convergence work come from the CAPWAP group?

I think it should, in order to have a coheive and truly interoperable
solution.  

-S

-----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

(implied)
> WTP<->AC are done diffrently) Local MAC data path: STA->WTP.
discussion

> > 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
> > >

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Fri, 27 Aug 2004 08:42:05 -0700

> 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. 

I respectfully disagree. The data plane is tied to the control channel because a WTP should only forward frames for a given user when it has received approval from the AC. The AC must make higher level access control decisions, not the WTP.

PatC

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Fri, 27 Aug 2004 11:31:39 -0600

Correct me if I am wrong - but Bert's assertion does not discount AC
being a PDP. The assertion is w.r.t. not to deal with

CAPWAP protocol enveloping or specifying how it should be encapsulated
or secured.

-mani

  _____  

Behalf Of Pat R. Calhoun
Sent: Friday, August 27, 2004 8:42 AM

> So... to me that sounds that we may potentially do an IMPLIED
agreement 

> data plane stuff, or at least that to me seems to be the wrong focus. 

I respectfully disagree. The data plane is tied to the control channel
because a WTP should only forward frames for a given user when it has
received approval from the AC. The AC must make higher level access
control decisions, not the WTP.

PatC

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Fri, 27 Aug 2004 11:18:10 -0700

I'm certainly not stating that L2TP is the right approach here, so my point was not whether an AC should be a
PDP. My point was that *like* L2TP, there has to be very close coordination between the data and control
path. These are not just open static GRE tunnels - there is policy enforcement and access control required
at the WTP, and this needs to be enforced by the AC.
 
PatC

________________________________

From: Mani, Mahalingam (Mahalingam) [mailto:[email-masked]]
Sent: Fri 8/27/2004 10:31 AM
To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC

Correct me if I am wrong - but Bert's assertion does not discount AC being a PDP. The assertion is w.r.t. not to deal with

CAPWAP protocol enveloping or specifying how it should be encapsulated or secured.

-mani

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pat R. Calhoun
Sent: Friday, August 27, 2004 8:42 AM
To: Wijnen, Bert (Bert); Shankar Narayanaswamy; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC

PatC

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Fri, 27 Aug 2004 12:41:12 -0600

Pat,

  _____  

From: Pat R. Calhoun [mailto:[email-masked]] 
Sent: Friday, August 27, 2004 11:18 AM
To: Mani, Mahalingam (Mahalingam); Wijnen, Bert (Bert); Shankar
Narayanaswamy; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Re: Data plane and control plane separation in
Split MAC

[Mani, Mahalingam (Mahalingam)] [....] My point was that *like* L2TP,
there has to be very close coordination between the data and control

path. These are not just open static GRE tunnels - there is policy
enforcement and access control required

[Mani, Mahalingam (Mahalingam)] I tend to agree completely. I did not
see that being ruled out - actually is well within scope of CAPWAP.

I will let Bert comment if he implied otherwise - I think not.

[Mani, Mahalingam (Mahalingam)] -mani

PatC

  _____  

To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy;

-mani

  _____  

agreement 

PatC

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 28 Aug 2004 13:49:29 +0200

Sorry, but I guess I do not exactly understand (yet) what you are talking about.
 
If you tell me that WTP to AC communication is over a standard XXX (for example GRE) tunnel,
then, I guess/think that it is fine to make such a  statement and to have management/control 
objects/items to be communicated over/with the CAPWAP protocol.
 
If you tell me that we must go down the path of specifying how data plane material gets encapsulated
on an XXX (whichever) tunnel, then I (personally) do not believe that that would be in scope for
the CAPWAP WG.
 
Does that help?

Thanks, Bert 

-----Original Message-----
From: Mani, Mahalingam (Mahalingam) [mailto:[email-masked]]
Sent: Friday, August 27, 2004 20:41
To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC

Pat,

  _____  

From: Pat R. Calhoun [mailto:[email-masked]] 
Sent: Friday, August 27, 2004 11:18 AM
To: Mani, Mahalingam (Mahalingam); Wijnen, Bert (Bert); Shankar Narayanaswamy; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC

[Mani, Mahalingam (Mahalingam)] [....] My point was that *like* L2TP, there has to be very close coordination between the data and control

[Mani, Mahalingam (Mahalingam)] I tend to agree completely. I did not see that being ruled out - actually is well within scope of CAPWAP.

PatC

  _____  

-mani

  _____  

PatC

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Sat, 28 Aug 2004 21:33:13 -0600

Bert,

My understanding of Pat's argument (I am unsure why he sets off
disagreeing) is that no matter what the data (encapsulation) protocol
WTP-level

access control mechanisms such as where/what traffic goes-to/comes-from
should be vested with AC.

That's what I mentioned agreeing on - as being a function of AC. That
does not per se say anything about data-plane protocol. If it is not as
simple

as that it needs more clarification as to why not - which I have not
heard so far. 

Regards,

-mani

  _____  

From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Saturday, August 28, 2004 4:49 AM
To: Mani, Mahalingam (Mahalingam); Pat R. Calhoun; Wijnen, Bert (Bert);
Shankar Narayanaswamy; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Re: Data plane and control plane separation in
Split MAC

Sorry, but I guess I do not exactly understand (yet) what you are
talking about.

If you tell me that WTP to AC communication is over a standard XXX (for
example GRE) tunnel,

then, I guess/think that it is fine to make such a  statement and to
have management/control 

If you tell me that we must go down the path of specifying how data
plane material gets encapsulated

on an XXX (whichever) tunnel, then I (personally) do not believe that
that would be in scope for

the CAPWAP WG.

Does that help?

Thanks, Bert 

	-----Original Message-----
	From: Mani, Mahalingam (Mahalingam) [mailto:[email-masked]]
	Sent: Friday, August 27, 2004 20:41
	To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy;

	Pat,

  _____  

	[Mani, Mahalingam (Mahalingam)] [....] My point was that *like*
L2TP, there has to be very close coordination between the data and
control

	path. These are not just open static GRE tunnels - there is
policy enforcement and access control required

	[Mani, Mahalingam (Mahalingam)] I tend to agree completely. I
did not see that being ruled out - actually is well within scope of
CAPWAP.

	PatC

  _____  

	Correct me if I am wrong - but Bert's assertion does not
discount AC being a PDP. The assertion is w.r.t. not to deal with

	CAPWAP protocol enveloping or specifying how it should be
encapsulated or secured.

	-mani

  _____  

[mailto:[email-masked]] On Behalf Of Pat R. Calhoun

agreement 

	> 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. 

	I respectfully disagree. The data plane is tied to the control
channel because a WTP should only forward frames for a given user when
it has received approval from the AC. The AC must make higher level
access control decisions, not the WTP.

	PatC

---

From: "Pat R. Calhoun" <[email-masked]>
Date: Mon, 30 Aug 2004 06:01:22 -0700

It sounds like we agree that some method must be provided to communicate the presence of a new station session, whose data is encapsulated within some form of a data transport. if I understand the issue you are raising, you wish to use an existing protocol, and not define a new one.
 
Interestingly enough, even though PPTP used GRE it still had to define how GRE was used for their protocol - a departure from the text defined in RFC 2637 (see section 4.1 - Enhanced GRE header), which I'm quite familiar with since I originally proposed the use of GRE for PPTP and came up with most of that text. So it's not clear to me that using stock 2784 is sufficient.
 
When you define a standards based approach, would UDP with a multiplexing layer (a la L2TP) not be considered standard?
 
PatC

From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Sat 8/28/2004 4:49 AM
To: Mani, Mahalingam (Mahalingam); Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy; [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC

 
 
Does that help?

Thanks, Bert 

	-----Original Message-----
	From: Mani, Mahalingam (Mahalingam) [mailto:[email-masked]]
	Sent: Friday, August 27, 2004 20:41
	To: Pat R. Calhoun; Wijnen, Bert (Bert); Shankar Narayanaswamy; [email-masked]
	Cc: [email-masked]
	Subject: RE: [Capwap] Re: Data plane and control plane separation in Split MAC

	Pat,

	PatC

	-mani

	PatC