Subject: Re: [Capwap] need clarification on UDP ports

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 26 Oct 2006 06:21:54 -0700

I doubt 1 byte (or 4 if we want alignment) will make that much of a
difference over the network. I think consistency of packet formats
across both planes will simplify product development, but more
importantly, troubleshooting.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Thursday, October 26, 2006 5:01 AM
> To: Pat Calhoun (pacalhou)
> Cc: Scott G. Kelly; Hasan Raza; [email-masked]; capwap
> Subject: Re: [Capwap] need clarification on UDP ports
> 
> 
> Hi Pat,
> 
> On Oct 26, 2006, at 6:44 AM, Pat Calhoun ((pacalhou)) wrote:
> > ok... no real objections on including an interim (short) tag to 
> > represent the packet type. If we are to go down this path, I would 
> > prefer that we maintain consistency across both the control 
> and data 
> > plane, and include the same header on both UDP ports. This 
> way, if a 
> > DTLS session is being used to secure the data plane, the 
> (relatively) 
> > same pre-parsing and security validation logic can be used.
> 
> That works for me, too
> 
> The main reason I had not suggested including the tag on both 
> control and data packets was that I was concerned about 
> lowering the MTU of the link for little benefit.  Is there 
> some reason why that isn't a concern?
> 
> Margaret
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Puneet Agarwal" <[email-masked]>
Date: Thu, 26 Oct 2006 14:37:30 -0700

Making the control and data ports format consistent is a good thing. I
support it for all the reasons listed in earlier emails.

Now that we have resolved how to demux encrypt/non-encrypt for capwap
control/data plane, I am hoping we can tackle the problem of multiple
QoS levels (the problem would be in capwap data and potentially in
capwap control plane) -  an issue first brought to the groups attention
by Scott.

The question to be resolved is:

Do we need per QoS anti-replay windows in dtls? If we support it, we
will need to maintain per QoS dtls session  for capwap data? A similar
number may be required for capwap control if we want to support multiple
QoS for capwap control too.

Furthermore, if we want to support per QoS anti-replay windows, it also
implies that the capwap QoS would need to be stored in the newly agreed
to "mux" shim. This is because the IP DSCP fields are subject to change
by the network.

If we go down this path, then we will need to define how to setup these
dtls sessions etc.

Comments?

-Puneet

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Thursday, October 26, 2006 6:22 AM
To: Margaret Wasserman
Cc: Scott G. Kelly; Hasan Raza; Puneet Agarwal; capwap
Subject: RE: [Capwap] need clarification on UDP ports

Pat Calhoun

> The main reason I had not suggested including the tag on both control 
> and data packets was that I was concerned about lowering the MTU of 
> the link for little benefit.  Is there some reason why that isn't a 
> concern?
> 
> Margaret
>