Subject: [Capwap] Negotiation for tunneling of user traffic (was: Taxonomy Recommendations)

From: "Darren Loher" <[email-masked]>
Date: Wed, 29 Jun 2005 16:00:21 -0700

Hi James,

I think the only way to avoid negotiation of where data is terminated is
if a CAPWAP protocol only supported one method of data termination.
(only terminated at the AC or only terminated at the WTP).  Certainly
that solution is simple, but it would not meet the traffic separation
objective which explicitly states a motivation to allow alternatives to
the WTP tunneling data back to the AC.  

I am not sure I can think of a way this can be done without somehow
negotiating tunneling of data.  However, how one solves for this does
not have to be extremely complex.  I'll use the SLAPP and CTP
submissions as examples.

SLAPP now has 5 WTP "mode" options.  Tunneling performed based on which
WTP "mode" is used.  The available modes are advertised by a WTP and the
AC "picks" which one is to be used.  This effectively negotiates weather
or not user data is tunneled to the AC based on the definitions of the 5
defined SLAPP modes.  That is just one way to do it.

CTP claims support of local MAC and split MAC modes independent of where
user data is terminated.  In addition, CTP defines its data message as
optional.  (so one does not have to implement a WTP with support for
tunneling user data)  I am not sure how CTP actually negotiates where
user data is terminated though.  (perhaps in a separate thread the CTP
authors could help me understand how this is handled in CTP?)

-Darren

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]]
> Sent: Wednesday, June 29, 2005 9:22 AM
> To: Darren Loher; Pat Calhoun; Sadot, Emek (Emek); [email-masked]
> Subject: [SUSPECT] Re: [Capwap] Taxonomy Recommendations
> 
> Darren,
> 
> While I think this may be an attractive idea, I think we need to
consider
> the impact on other requirements. As pointed out by Pat, there may be
some
> impact on handover performance. If the data plane is constrained to
run
> through the AC, the AC needs only rewrite a few fields in an in-memory
> record in order to move link routing from one AP to another. The
control
> interface between the AC and the distribution function in essentially
an
> API> If the data plane is not so constrained, is a requirement for an
> additional protocol interface between the AC and the WTP. This may end
up
> slowing handover. These issues could become clearer if there were a
> mapping
> of functional architecture to a few network reference architectures,
in
> which the interfaces between functional elements were classified as
either
> interior to network entities (i.e. an API) or between them (i.e. a
> protocol).
> 
> In addition, last year someone, I think Dan, brought up the issue of
> additional complexity. If the AC supports both options, then the AC
and
> WTP
> must negotiate the tunnel protocol (or not, if the WTP is performing
> distribution). This makes the protocol more complex.
> 
> So the result is that there may be some tradeoffs in the objectives,
in
> which some conflict, and I think prioritization may be necessary.
> 
>             jak
> 
> 
> ----- Original Message -----
> From: "Darren Loher" <[email-masked]>
> To: "Pat Calhoun" <[email-masked]>; "Sadot, Emek (Emek)"
> <[email-masked]>; "James Kempf" <[email-masked]>;
> <[email-masked]>
> Sent: Tuesday, June 28, 2005 4:14 PM
> Subject: RE: [Capwap] Taxonomy Recommendations
> 
> 
> Although certain implementations may constrain which tunneling options
> are available depending on split or local MAC, I don't think we have
to
> assume this in the capwap protocol.
> 
> As James Kempf pointed out:
> jak>> So it seems you are proposing to separate the control and data
> jak>> plane, and then some way in the control protocol to negotiate
how
> jak>> the data plane is handled? Is that correct?
> 
> After James pointed it out I understood better what Emek is looking
for.
> I think this is a great idea.
> 
> We already have consensus that the CAPWAP protocol must support the
> ability to split user data from control and management data.  This
split
> is meant to enable flexibility on how user traffic is terminated onto
> the wired network.  The CAPWAP protocol should not tightly associate
the
> permutations of how traffic can be split in the different
architectures.
> 
> 
> CAPWAP should allow an AC to configure a WTP to:
> - bridge 802.11 data traffic locally at the WTP
> - tunnel 802.11 data traffic to the AC
> And independently the AC should be able to configure a WTP to:
> - terminate & process 802.11 control and mgmt traffic locally
> - tunnel 802.11 control and mgmt traffic to the AC
> 
> However, I also propose that an implementor should be given the option
> to create a solution which only supports a subset of the possible
> permutations of user and control traffic separation.  To support this
> flexibility, the WTP could advertise its tunneling capabilities.
> 
> -Darren
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
On
> > Behalf Of Pat Calhoun
> > Sent: Tuesday, June 28, 2005 4:11 PM
> > To: 'Sadot, Emek (Emek)'; 'James Kempf'; [email-masked]
> > Subject: RE: [Capwap] Taxonomy Recommendations
> >
> > One question I do have for you is that if your vision of the CAPWAP
> > protocol
> > is really a negotiation of various features allowing for any
> permutation,
> > then why is our definition binary (meaning split vs. local). In your
> mind
> > what consistutes a split vs local architecture, and why do we need
two
> > modes
> > of operation vs one mode that can negotiate a number of
configuration
> > parameters.
> >
> > WRT the NAT text, I was trying (unsuccessfully) to provide an
example
> > where
> > centralization of services makes sense. The example here was NAT.
> Imagine
> > if
> > NAT was implemented on every WTP. As you know, a NAT keeps track of
> all
> > flows for an individual user, and when a mobility event occurs, the
> flow
> > state would have to be transferred from one WTP to another - a
> difficult
> > problem to resolve. Hence such advanced services are natural ones to
> be
> > centralized in the AC.
> >
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit
> > Cisco Systems
> >
> >
> >
> > > -----Original Message-----
> > > From: Sadot, Emek (Emek) [mailto:[email-masked]]
> > > Sent: Monday, June 27, 2005 11:15 PM
> > > To: Pat Calhoun; James Kempf; [email-masked]
> > > Subject: RE: [Capwap] Taxonomy Recommendations
> > >
> > > Pat,
> > >
> > > We will just have to agree to disagree on whether or not the
> > > CAPWAP protocol should serve as a platform for
> > > more-then-just-two distinct architectures.
> > >
> > > I fail to see the NAT problem you described.
> > >
> > > Regards,
> > > Emek
> > >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Pat Calhoun
> > > Sent: Tuesday, June 21, 2005 5:34 PM
> > > To: Sadot, Emek (Emek); 'James Kempf'; [email-masked]
> > > Subject: RE: [Capwap] Taxonomy Recommendations
> > >
> > > Emek,
> > >
> > > I'd like to address the two main points you've made in your
e-mail.
> > >
> > > 1. Keep the data path short. I agree that there are some
> > > challenges when an AC is situated very far from the WTP, and
> > > that's the exact reason why one does need what I call Local
> > > AP in the taxonomy recommendations draft.
> > > However, most "CAPWAP-like" deployments out there really
> > > don't fall under the category you mention - all ACs are
> > > located topologically near the the WTPs, and in such cases
> > > having the data path centralized allows a powerful AC to
> > > perform many policy, security and mobility related functions
> > > that would be hard to do on a standalone WTP (but by being
> > > centralized allows for these functions to execute even across
> > > mobility events). Just using one example, what if NAT were to
> > > be provided on the WTP, how could the network converge in
> > > understanding what flows are active, and the related port
> > > mapping? Hence my recommendation for Split and Local AP -
> > > where the former tunnels the data to the AC and the latter
> > > does not. The customer can use one or the other, mostly based
> > > on topological requirements.
> > > 2. Single point of failure. I've addressed this in prior
> > > e-mails, and the LWAPP protocol addresses this. Further, if a
> > > WTP relies on an AC, you have a point of failure regardless.
> > > So this needs to be addressed in a protocol, and it's not
> > > just the data path that's at stake here.
> > >
> > > I realize we're not in complete agreement on this topic yet,
> > > but I still do believe that reducing the options is a
> > > feature, not a bug.
> > >
> > > Pat Calhoun
> > > CTO, Wireless Networking Business Unit
> > > Cisco Systems
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Sadot, Emek
(Emek)
> > > > Sent: Monday, June 20, 2005 11:43 PM
> > > > To: James Kempf; Pat Calhoun; [email-masked]
> > > > Subject: RE: [Capwap] Taxonomy Recommendations
> > > >
> > > > Jak
> > > >
> > > > The main reason I see to bridge frames at the WTP is to
> > > keep session's
> > >
> > > > shortest path (diminish delay, latency, jitter, etc., for
> real-time
> > > > application such as VoWLAN). For example:
> > > > AC at NYC and WTP located at London; London office has two or
> three
> > > > legs to the external world: (a) VPN/FR/Lease line to NYC
> > > main office,
> > > > (b) local PSTN link and (c) local Internet service / exist to
> local
> > > > ISP. Wi-Fi voice call from London office better not be traveled
> via
> > > > NYC if not absolutely necessary.
> > > >
> > > > AC as a single point of failure is another point. Sustain
existing
> > > > Wi-Fi sessions while AC experience failure or experience network
> > > > outage between WTP and AC.
> > > >
> > > > These are my points, other may have different view which is
> > > perfectly
> > > > fine. Different architectures address different environments and
> > > > different solutions. Just because a vendor can't figure out how
> > > > another may solve a perceived problem doesn't mean it can't be
> done
> > > > nor is it relevant to CAPWAP.
> > > >
> > > > I believe the group need to come up with a mechanism /
> > > process of how
> > > > to decide on labor division. Only two distinctive options,
> > > Split and
> > > > Local, is a bit too restricted.
> > > >
> > > > If I am not mistake there were four objectives which ignite
> > > > CAPWAP: (a) AP is an IP-addressable device requiring management,
> > > > monitoring, and control (b) Distributing and maintaining a
> > > consistent
> > > > configuration, (c) Difficulty in dealing effectively with
> > > the dynamic
> > > > nature of large WLAN and
> > > > (d) Securing access to the network and preventing installation
of
> > > > unauthorized AP.
> > > >
> > > > CAPWAP is about Control and Provisioning. It says nothing about
> the
> > > > user's data frames path.
> > > > One more point, it's not mandatory that AC will be a dedicated
HW
> > > > appliance. It could be a piece of software runs on any platform.
> > > > Overwhelming the AC with user's data implicitly dictates the
> former.
> > > >
> > > > It should be the other way around - one should come with a
> > > very good
> > > > reason to execute bridging at the AC. In my opinion the
> > > protocol shell
> > >
> > > > facilitate both, letting the operator the freedom to chose.
> > > > To name a few reasons to consider bridging at the AC:
> > > > 1. Statistics: AC can extract raw statistics / info from
> > > > 802.11 frames.
> > > > 2. Apply policy at the AC rather then at the WTP - simpler WTP.
> > > > 3. If AC is a Layer 3 roaming facilitator.
> > > > 4. If AC implements 802.11 encryption / decryption.
> > > >
> > > > (apologize, it turn out the answer is a bit too long that I
> > > > expected) Emek
> > > >
> > > > -----Original Message-----
> > > > From: James Kempf [mailto:[email-masked]]
> > > > Sent: Monday, June 20, 2005 8:22 PM
> > > > To: Sadot, Emek (Emek); Pat Calhoun; [email-masked]
> > > > Subject: Re: [Capwap] Taxonomy Recommendations
> > > >
> > > > Emek,
> > > >
> > > > Take for example the IS service: where it fits in Slit and
> > > Local - WTP
> > >
> > > > or AC? I would disagree the authors conclusion (section 5 first
> > > > bullet) w.r.t. bridging function, and believes we can, and
should,
> > > > allow the operator to chose.
> > > >
> > > > jak>> OK, so what criteria would cause an operator to choose
> > > > bridging at
> > > >
> > > > jak>> the
> > > > WTP versus bridging at the AC?
> > > >
> > > >         jak
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 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