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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 18 Dec 2006 18:52:18 -0800

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

 -----Original Message-----
From: 	Puneet Agarwal [mailto:[email-masked]]
Sent:	Monday, December 18, 2006 06:40 PM Pacific Standard Time
To:	Charles Clancy; Jim Murphy
Cc:	capwap
Subject:	Re: [Capwap] Necessity of Session ID in unencrypted Data Channel

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.

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

---

From: Jim Murphy <[email-masked]>
Date: Tue, 19 Dec 2006 12:29:13 -0800

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
>