Subject: [Capwap] Additions #10 - Support for Traffic Separation

From: "Saravanan Govindan" <[email-masked]>
Date: Wed, 23 Feb 2005 17:50:14 +0800

Additions #10 - Support for Traffic Separation

Issue: 

Include subsection 5.2.3ii-'Mutual separation of Control and Communications' in
Objective-5.2.7-'Support for Traffic Separation'. Proposed changes are to be made to Objective-5.2.7

Proposed change: 

Classification: Operational                                                     

Priority: Mandatory                                                             

Description: 

(Insert after first paragraph) 
Furthermore, in the context of shared infrastructure, the mutual separation of data and control also
addresses security concerns.                          

(Insert after second paragraph) 
And in shared infrastructure WLANs, which may contain traffic belonging to different logical groups
with possibly varying needs, it is important that each group's traffic be separated.

Protocol Requirement: The CAPWAP protocol should separate transport of control and data information.

Motivation and Protocol Benefits: 

(Insert after second paragraph) 
Separation of WTP control and data allows for secure realization of shared WLANs.

Relation to Problem Statement: 
(Insert after first sentence) 
This objectives allows for simplified control as this can be separated from the task of data
transport. 

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 23 Feb 2005 08:59:25 -0800

What is meant by "separation of control and data"? That the AC must be a
separate network element from switching and routing equipment that handles
user traffic? Or just that the CAPWAP control protocol is only concerned
with control, and not with user traffic? There's a big difference between
these two. I think this requirement needs to be clearer.

            jak

---

From: "Saravanan Govindan" <[email-masked]>
Date: Thu, 24 Feb 2005 17:43:41 +0800

Hi James,

This requirement if for the CAPWAP protocol to deal with control independent of user data traffic.
While the control aspects can be used to set up the exchange of user data traffic, the two are to be
independent of each other.

Cheers,

Saravanan

> -----Original Message-----
> From: James Kempf [mailto:[email-masked]] 
> Sent: Thursday, February 24, 2005 12:59 AM
> To: Saravanan Govindan; [email-masked]
> Subject: Re: [Capwap] Additions #10 - Support for Traffic Separation
> 
> What is meant by "separation of control and data"? That the 
> AC must be a separate network element from switching and 
> routing equipment that handles user traffic? Or just that the 
> CAPWAP control protocol is only concerned with control, and 
> not with user traffic? There's a big difference between these 
> two. I think this requirement needs to be clearer.
> 
>             jak
> 
> > Objective-5.2.7-'Support for Traffic Separation'. Proposed 
> changes are to
> be made to Objective-5.2.7
> >
> >
> > Proposed change:
> >
> > And in shared infrastructure WLANs, which may contain 
> traffic belonging to
> different logical groups
> > with possibly varying needs, it is important that each 
> group's traffic be
> separated.
> >
> >
> >
> > Protocol Requirement: The CAPWAP protocol should separate 
> transport of
> control and data information.
> >
> >
> >
> > Separation of WTP control and data allows for secure 
> realization of shared
> WLANs.
> >
> >
> >
> > This objectives allows for simplified control as this can 
> be separated
> from the task of data
> > transport.
> >

---

From: "James Kempf" <[email-masked]>
Date: Thu, 24 Feb 2005 10:23:10 -0800

I'm still not sure I understand what constraints this places on the
protocol.

Does this capture it:

"In order to maintain separation of control and data traffic, the CAPWAP
protocol is required to define control messages such that they do not
involve piggybacking or other combination with terminal data traffic."

This would, for example, rule out using an IPv6 Header Option that could be
piggybacked on other data traffic (note that I just proposing this as an
example).

            jak