Subject: Re: [Capwap] Necessity of Session ID in unencrypted Data Channel

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 19 Dec 2006 11:54:55 -0800

Actually, one could simply send a NULL 802.11 data frame periodically.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Puneet Agarwal [mailto:[email-masked]] 
> Sent: Monday, December 18, 2006 10:52 PM
> To: Scott G Kelly
> Cc: capwap
> Subject: Re: [Capwap] Necessity of Session ID in unencrypted 
> Data Channel
> 
> Hi Scott,
> 
> This pkt needs to be periodic otherwise the nat state in the 
> nat gateway will get timed out during extended periods of 
> capwap data inactivity. 
> 
> This again is an artifact of a separate tunnel for data vs 
> control. If needed, we will need to tie it to the protocol 
> exchange (I agree).
> 
> Thanks
> 
> Puneet
> 
> Sent from my handheld enabled by Broadcom EDGE/GPRS/GSM 
> Processor and Bluetooth Technologies (www.broadcom.com)
> 
>  -----Original Message-----
> From: 	Scott G Kelly [mailto:[email-masked]]
> Sent:	Monday, December 18, 2006 08:05 PM Pacific Standard Time
> To:	Puneet Agarwal
> Cc:	Charles Clancy; Jim Murphy; capwap
> Subject:	Re: [Capwap] Necessity of Session ID in 
> unencrypted Data Channel
> 
> Puneet Agarwal wrote:
> > I agree with Charles. It should not be too hard to guarantee a 
> > keepalive to be sent on the data-channel before other traffic.
> > 
> > Looks like we can take out the session id from the regular 
> capwap data 
> > frames.
> > 
> 
> There's a little more to specify: the initial data channel 
> packet containing the sessionID MUST be acknowledged before 
> any data is sent. 
> Otherwise, if the set-up packet is lost, the subsequent data 
> must be dropped by the AC, and there is no defined way to let 
> the WTP know it needs to send the sessionID again.
> 
> This approach saves you 8 bytes per data packet at the cost 
> of additional connection set-up latency (and a small amount 
> of added complexity). Given that this is a "special" 
> connection setup packet, I'm not sure calling it a keepalive 
> is appropriate. It seems like if we are going to take this 
> approach, it might make sense to define a specific protocol 
> exchange for this purpose.
> 
> Scott
> 
> > Thanks.
> > 
> > -Puneet
> > 
> > -----Original Message-----
> > From: Charles Clancy [mailto:[email-masked]]
> > Sent: Monday, December 18, 2006 5:54 AM
> > To: Jim Murphy
> > Cc: capwap
> > Subject: Re: [Capwap] Necessity of Session ID in unencrypted Data 
> > Channel
> > 
> > Jim,
> > 
> > We'd have to guarantee that a keep-alive was sent before any other 
> > packets on the data channel.  Then correlation could be 
> done based on 
> > the DTLS context or ip/port (if data channel unencrypted).  If so, 
> > then it should be okay.
> > 
> > --
> > t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy
> > 
> > Jim Murphy wrote:
> >> Hi,
> >>
> >> I would like to open up a discussion on the list regarding the 
> >> necessity of the session ID in the unencrypted data channel.
> >>
> >> The argument for the session ID is to allow one to correlate the 
> >> control and data channels when addresses and ports are modified by 
> >> NAT
> > 
> >> devices.
> >>
> >> The downside of the session ID is additional overhead in 
> the CAPWAP 
> >> tunneling encapsulation. We can have arguments about how bad this 
> >> overhead is in the real world, but it is clear that forwarding 
> >> performance and scaling using CAPWAP will be worse than existing 
> >> solutions that have smaller encapsulation headers.
> >>
> >> As has been discussed on the list in the past, in order to 
> maintain 
> >> the state in the NAT device, the data channel will require 
> periodic 
> >> keep-alives. This email proposes that only the periodic 
> keep-alives 
> >> must contain the session ID, note that the session ID need not be 
> >> part
> > 
> >> of the CAPWAP header. When an AC receives a keep-alive on the data 
> >> channel it can correlate data channel address and ports with the 
> >> control channel and plum the forwarding path accordingly.
> >>
> >> Thanks,
> >>
> >> Jim
> >>
> >> _________________________________________________________________
> >> To unsubscribe or modify your subscription options, please visit:
> >> http://lists.frascone.com/mailman/listinfo/capwap
> >>
> >> Archives: http://lists.frascone.com/pipermail/capwap
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/capwap
> > 
> > Archives: http://lists.frascone.com/pipermail/capwap
> > 
> > 
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/capwap
> > 
> > Archives: http://lists.frascone.com/pipermail/capwap
> > 
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> 
_________________________________________________________________
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: Wed, 20 Dec 2006 06:51:40 -0800

The best way to consider your idea is for you to submit proposed text.

Proposed text for both the session id and the preamble headers have been
available for well over three weeks, so I am hoping that people have had
a chance to review it.

Pat Calhoun

> From: Jim Murphy [mailto:[email-masked]] 
> Sent: Tuesday, December 19, 2006 12:29 PM
> To: Pat Calhoun (pacalhou)
> Cc: capwap
> Considering that neither the session ID nor the MUX header 
> have made their way into a published draft, I wonder if 
> enough people have had a chance to consider the implications 
> of these additions to the data plane and therefore if we are 
> not premature in going into last call.
> 
> When comparing the -03 draft with what is likely to be 
> contained in the
> -04 draft, there is a 12 byte increase over what was a 
> concise 8 byte header. This is a 24% increase over the total 
> L2, IP, UDP and -03 CAPWAP header. This will have a direct 
> impact on per packet memory bandwidth requirements and 
> processor cache behavior. It will also impact scaling in 
> terms of (expensive) memory requirements in hardware 
> implementations. I think we should take a little time now to 
> decide if this avoidable cost is acceptable.
> 
> Thanks,
> 
> Jim
> 
> 
> Pat Calhoun (pacalhou) wrote:
> > Given the time remaining before we go to last call, and number of 
> > issues still pending, do we honestly feel that introducing 
> a signaling 
> > plane in the data channel is really that crucial?
> > 
> > PatC
> > 
> > Sent:   Monday, December 18, 2006 06:40 PM Pacific Standard Time
> > To:     Charles Clancy; Jim Murphy
> > Cc:     capwap
> unencrypted Data 
> >  > I would like to open up a discussion on the list 
> regarding the  > 
> >  > The argument for the session ID is to allow one to 
> correlate the  > 
> > control and data channels when addresses and ports are 
> modified by NAT
> > 
> >  > devices.
> >  >
> > > tunneling encapsulation. We can have arguments about how 
> bad this  > 
> > overhead is in the real world, but it is clear that forwarding  > 
> > performance and scaling using CAPWAP will be worse than existing  > 
> >  > As has been discussed on the list in the past, in order 
> to maintain  
> > > the state in the NAT device, the data channel will 
> require periodic  
> > > channel it can correlate data channel address and ports 
> with the  >