Subject: Re: [Capwap] Data and Control paths, was: Re: Comments on -02 version of capwap spec

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sun, 17 Sep 2006 13:21:45 -0700

Dave, I will make an additional change in figures 5 and 7 (with
associated text) to cover your request.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]] 
> Sent: Sunday, September 17, 2006 9:28 AM
> To: Abhijit Choudhury
> Cc: Pat Calhoun (pacalhou); Puneet Agarwal; 
> [email-masked]; [email-masked]
> Subject: Data and Control paths, was: Re: [Capwap] Comments 
> on -02 version of capwap spec
> 
> HI,
> 
> Several of the proposals for the base capwap document specified that
> 802.11 control messages and 802.1X messages were encapsulated 
> in CAPWAP control messages. So, some believed (and maybe 
> implemented) such approaches.
> 
> It would be extremely useful to show the actual packet flows 
> to compare and contrast "stand-alone AP", "local-MAC WTP with 
> AC", and "split-MAC WTP with AC". I'm not sure this is well 
> understood by the WG, nor explained well in the CAPWAP spec.
> 
> Regards,
> /david t. perkins
> 
> On Sun, 17 Sep 2006, Abhijit Choudhury wrote:
> >             [Puneet]: My main concern is the way 802.11 
> Management traffic
> >             is handled today. It wasn't clear to me why we 
> (the group) specified to
> >             carry them in CAPWAP Data frames. I would have 
> thought that they would
> >             be carried in CAPWAP Control Frames as they 
> would most likely be handled
> >             by the CAPWAP Control entity (and not 
> necessarily the CAPWAP Data
> >             entity). Hence sending such packets to the 
> CAPWAP Data entity seems like
> >             a waste and it would eventually need to be sent 
> to the CAPWAP control
> >             entity.
> > 
> >         <PRC> I think architecturally, I disagree. I 
> believe that the CAPWAP
> >               Control entity handles the base spec - 
> maintaining that connection and
> >               configuration with the peer. The CAPWAP Data 
> entity, on the other hand,
> >               is the one that actually understands the 
> subtleties of 802.11 (or
> >               whatever wireless binding). It handles the 
> user associations, the 802.1x
> >               state machine, etc. Further, as I noted 
> above, it becomes complex to
> >               decide what's management and what's not. 
> Clearly, an 802.11 MAC
> >               management frame would be a candidate, but 
> what about EAPOL? What about
> >               IAPP? This would require use to do an 
> extensive protocol survey and list
> >               the proper destination for each.
> > 
> >  
> > I agree with Pat here. The current architecture hands it cleanly. 
> > Sending 802.11 management traffic on the control channel 
> would cause 
> > lots of problems unless the 802.1X and 4-way handshake were also 
> > carried on the control channel.
> > Since the latter are carried in 802.11 data packets, they 
> definitely 
> > belong on the data channel.
> >  
> > I think the real problem is that the 802.3 tunneling mode 
> has not been 
> > fully specified.  It's not clear how the
> > 802.11 management frames will be carried in the data 
> channel in 802.3 
> > tunneling mode.
> >  
> > Thanks,
> >    Abhijit
> > 
> >  
> > 
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sun, 17 Sep 2006 13:24:26 -0700

Oh, and I created issue 222 for this.

Pat Calhoun

> From: Pat Calhoun (pacalhou) 
> Sent: Sunday, September 17, 2006 1:22 PM
> To: 'David T. Perkins'; Abhijit Choudhury
> Cc: Puneet Agarwal; [email-masked]; [email-masked]
> Subject: RE: Data and Control paths, was: Re: [Capwap] 
> Comments on -02 version of capwap spec
> 
> Dave, I will make an additional change in figures 5 and 7 
> (with associated text) to cover your request.
> 
> Pat Calhoun
> > Cc: Pat Calhoun (pacalhou); Puneet Agarwal; [email-masked]; 
> > [email-masked]
> > Subject: Data and Control paths, was: Re: [Capwap] Comments on -02 
> > version of capwap spec
> > 
> > HI,
> > 
> > 802.11 control messages and 802.1X messages were encapsulated in 
> > CAPWAP control messages. So, some believed (and maybe
> > It would be extremely useful to show the actual packet flows to 
> > compare and contrast "stand-alone AP", "local-MAC WTP with AC", and 
> > "split-MAC WTP with AC". I'm not sure this is well 
> understood by the 
> > WG, nor explained well in the CAPWAP spec.
> > 
> > Regards,
> > /david t. perkins
> >