Subject: [Capwap] Use of SESSION ID

From: "David T. Perkins" <[email-masked]>
Date: Thu, 1 Jun 2006 15:22:47 -0700 (PDT)

HI,

The join request operation contains the "Session ID" information
element. Where is this used after the join? Is it somehow related
to the DTLS session ID?

Regards,
/david t. perkins

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 1 Jun 2006 15:48:37 -0700 (GMT-07:00)

Hi David,

Good catch - I think that got lost in the shuffle of the various header changes. The session ID is required for capwap processing, and is independent of the DTLS session (and you need it for the data channel, too). I think it needs to be included in the generic capwap header. That is currently defined as follows:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Version|   RID   | HLEN  |F|L|W|M|            Flags            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Fragment ID          |     Frag Offset         |Rsv-2|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 (optional) Radio MAC Address                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            (optional) Wireless Specific Information           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        Payload ....                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

But it should probably be like this, instead:

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Version|   RID   | HLEN  |F|L|W|M|            Flags            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Fragment ID          |     Frag Offset         |Rsv-2|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          Session ID                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 (optional) Radio MAC Address                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            (optional) Wireless Specific Information           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        Payload ....                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

--Scott

-----Original Message-----
>From: "David T. Perkins" <[email-masked]>
>Sent: Jun 1, 2006 3:22 PM
>To: [email-masked]
>Subject: [Capwap] Use of SESSION ID
>
>HI,
>

---

From: "Abhijit Choudhury" <[email-masked]>
Date: Fri, 2 Jun 2006 11:48:12 -0700

Interesting....

If we are carrying a SessionId in the CAPWAP header,
it opens up lots of possibilities.  

Here're some thoughts:

1. Currently, as proposed below, the SessionID is
   in the CAPWAP header and that is inside the DTLS
   payload.  I'm not sure why the format cannot be 

      IP/UDP/CAPWAP/DTLS/payload

   instead of 
      IP/UDP/Shim/DTLS/CAPWAP/payload

   There is nothing really confidential in the CAPWAP
   header, and so there is no reason it cannot 
   be outside the DTLS.  If it is outside, it could
   very well indicate the Data/Control information,
   as well as the SessionId.
   
2. If the session ID is available outside the DTLS
   payload it's possible to support 2 separate UDP
   ports for control and data.  The SessionId can
   be used to bind them even if there are NAT boxes
   the path.

3. Even if you don't agree to (1), we can put the
   sessionId in the Shim and be able to support 
   2 separate UDP ports based on (2).

4. We need some indication in the header itself
   to show if the Data payload is DTLS encrypted.
   There could very well be some data sessions that
   have DTLS encryption and some that don't.

Thanks,
   Abhijit

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Thursday, June 01, 2006 3:49 PM
To: David T. Perkins; [email-masked]
Subject: Re: [Capwap] Use of SESSION ID

Hi David,

Good catch - I think that got lost in the shuffle of the various header
changes. The session ID is required for capwap processing, and is
independent of the DTLS session (and you need it for the data channel,
too). I think it needs to be included in the generic capwap header. That
is currently defined as follows:

         0                   1                   2                   3
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Version|   RID   | HLEN  |F|L|W|M|            Flags
|
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Fragment ID          |     Frag Offset
|Rsv-2|
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 (optional) Radio MAC Address
|
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            (optional) Wireless Specific Information
|
 
        |                        Payload ....
|

         0                   1                   2                   3
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |Version|   RID   | HLEN  |F|L|W|M|            Flags
|
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |          Fragment ID          |     Frag Offset
|Rsv-2|
 
        |                          Session ID
|
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                 (optional) Radio MAC Address
|
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            (optional) Wireless Specific Information
|
 
        |                        Payload ....
|

--Scott

-----Original Message-----
>element. Where is this used after the join? Is it somehow related to 
>the DTLS session ID?
>
>Regards,
>/david t. perkins
>

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Fri, 2 Jun 2006 12:02:23 -0700

Abhijit,

The use of the CAPWAP header to distinguish between control and data
suffers from all the same problems that using a custom shim for that
purpose, i.e., there is not a router or switch in the world that
understands either one.

 -Bob
 
-----Original Message-----
From: Abhijit Choudhury [mailto:[email-masked]] 
Sent: Friday, June 02, 2006 11:48 AM
To: Scott G. Kelly; David T. Perkins; [email-masked]; Pat Calhoun
(pacalhou)

Interesting....

Here're some thoughts:

   instead of 

Thanks,
   Abhijit

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Thursday, June 01, 2006 3:49 PM
To: David T. Perkins; [email-masked]
Subject: Re: [Capwap] Use of SESSION ID

Hi David,

         0                   1                   2                   3

 

 

         0                   1                   2                   3

 

 

--Scott

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 2 Jun 2006 16:21:03 -0700 (GMT-07:00)

-----Original Message-----
>From: "Bob O'Hara (boohara)" <[email-masked]>
>Sent: Jun 2, 2006 12:02 PM
>To: [email-masked]

Ummm... that's definitely not right. The *airespace* switch has no problem understanding this, nor do other vendors *wlan* switches, if they want to update their firmware and/or microcode accordingly. This talk about "custom shims" is misdirection. What's custom here is what you guys are proposing.

Backward compatibility with a particluar vendor's legacy network gear in terms of identifying capwap internals is not a stated goal of this working group, nor should it be. It's not in the objectives draft, the architectural taxonomy, or the working group charter. And it's not in the interest of the broader community - vendors *or* customers.

--Scott

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 2 Jun 2006 16:27:40 -0700 (GMT-07:00)

Hi Abhijit,

I thought about this quite a bit overnight, and realized I jumped the gun in replying to David's initial post. I think David is right, if you assume a mux header: since the dtls session is identified by source IP/port, and the control channel and data channel live and die together, there is no need for a session ID in that case. The session is entirely identified by source IP address and port (and the data channel is tightly bound to the control channel).

Scott

-----Original Message-----
>From: Abhijit Choudhury <[email-masked]>
>Sent: Jun 2, 2006 11:48 AM
>To: "Scott G. Kelly" <[email-masked]>, "David T. Perkins" <[email-masked]>, [email-masked], "Pat Calhoun (pacalhou)" <[email-masked]>
>Subject: RE: [Capwap] Use of SESSION ID
>
>Interesting....
>

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Fri, 2 Jun 2006 16:56:44 -0700

Scott,

Misdirection, or maybe it is truly not understanding what is in your own
networking closet, is not justification for this ad hominem attack.
Your clever switch of terminology to substitute "switch" for "AC" does
not change the way the world's networking equipment works today.

What I said below, and have said earlier, and have had supported by
several others on this list is that the devices in the network
infrastructure, the world's switches and routers, do not understand
CAPWAP (or LWAPP for that matter) and likely never will.  This battle is
over, regardless of your claim of misdirection.  Putting any kind of
custom header behind UDP and expecting the world's network
infrastructure to adapt to it, simply because you like it, is a pipe
dream.  

If we want CAPWAP to be widely adopted, we need to ensure it is going to
work in the infrastructure that it lands in.  Any expectation that the
Internet will adapt to CAPWAP will doom CAPWAP to the dust bin of "nice
idea, but stupid implementation".

 -Bob
 
-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Friday, June 02, 2006 4:21 PM
To: Bob O'Hara (boohara); [email-masked]
Subject: Re: [Capwap] Use of SESSION ID

-----Original Message-----
>purpose, i.e., there is not a router or switch in the world that

Ummm... that's definitely not right. The *airespace* switch has no
problem understanding this, nor do other vendors *wlan* switches, if
they want to update their firmware and/or microcode accordingly. This
talk about "custom shims" is misdirection. What's custom here is what
you guys are proposing.

Backward compatibility with a particluar vendor's legacy network gear in
terms of identifying capwap internals is not a stated goal of this
working group, nor should it be. It's not in the objectives draft, the
architectural taxonomy, or the working group charter. And it's not in
the interest of the broader community - vendors *or* customers.

--Scott

---

From: "Abhijit Choudhury" <[email-masked]>
Date: Fri, 2 Jun 2006 17:31:22 -0700

Bob,

I have already addressed your concern in one 
of the proposals in my earlier email.  
If you look at point (2) below, separate UDP 
ports are used for control and data.
However, we still need to solve the following
two problems:

1. NAT traversal: That's where the SessionId
  in the CAPWAP header can help. It can bind
  the control and data channels together even
  if there is a NAT box in between the WTP and AC.

2. DTLS: For (1) to work, the SessionId needs
   to be outside the DTLS payload. That's why the
   the CAPWAP header carrying the sessionID 
   needs to be outside the DTLS payload. 
   
The result is an architecture that uses two 
separate UDP ports for control and data and can
support both NAT traversal as well as optional DTLS on 
the data path.
The packet format would be:

Thanks,
   Abhijit

-----Original Message-----
From: Bob O'Hara (boohara) [mailto:[email-masked]] 
Sent: Friday, June 02, 2006 12:02 PM
To: [email-masked]
Subject: Re: [Capwap] Use of SESSION ID

Abhijit,

 -Bob
 
-----Original Message-----
From: Abhijit Choudhury [mailto:[email-masked]] 
Sent: Friday, June 02, 2006 11:48 AM
To: Scott G. Kelly; David T. Perkins; [email-masked]; Pat Calhoun
(pacalhou)

Interesting....

Here're some thoughts:

   instead of 

Thanks,
   Abhijit

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Thursday, June 01, 2006 3:49 PM
To: David T. Perkins; [email-masked]
Subject: Re: [Capwap] Use of SESSION ID

Hi David,

         0                   1                   2                   3

 

 

         0                   1                   2                   3

 

 

--Scott

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 2 Jun 2006 17:32:09 -0700 (GMT-07:00)

Hi Bob,

I'm sorry that you interpreted my comment as a personal attack - it certainly was not intended to be. 

That's all the energy I have for this debate this Friday evening. Have a nice weekend.

Scott

-----Original Message-----
>Sent: Jun 2, 2006 4:56 PM
>To: [email-masked]

---

From: "Partha Narasimhan" <[email-masked]>
Date: Sun, 4 Jun 2006 13:06:53 -0700

I am finding it hard to understand some of the reasoning put forth on
the list on why we need two UDP ports - one each for data and control. 

If a few intermediate network devices on the path from the ACs to the
WTPs are incapable of classifying traffic based on fields existing in
the standard IP header, then it merely means that certain network
configurations are not feasible when designing networks to suit specific
WLAN network requirements in the presence of such network devices. For
example, in the presence of such devices, one can always operate the
network in Local MAC mode with local termination of IEEE 802.11 at the
WTP. One can also design a split MAC solution except we may have to
dimension the network properly so that we stay within the bounds imposed
by not being able to classify and handle different traffic types
differently in the intermediate network. 

Assuming for the sake of argument that going down the path of two UDP
ports is the only possible solution to dealing with limitations of the
intermediate network, how do we see WMM/11e traffic being handled in
such scenarios in the intermediate network when all the data traffic
goes on a single UDP port assigned for CAPWAP data? Does this mean that
we assign multiple UDP ports for CAPWAP data - one each for every
WMM/11e AC? Obviously, that doesn't scale. 

Designing a protocol that covers most of the intermediate network
topologies as opposed to all topologies does not mean that the entire
protocol is useless, just merely that limitations in the intermediate
network could prevent a WLAN network designer from being able to use the
full potential of the protocol. Network design, as with any other
engineering discipline, has to deal with a set of trade-offs and it is
no different here. 

Going down the path of two separate UDP ports, one each for control and
data, adds significant complexity to the protocol and the state machine
as has been presented before on other prior threads. If a majority of
the devices that we expect to encounter in the intermediate network do
not have such limitations, then we cannot choose to impose this
complexity on the networks that do not have to deal with significantly
higher complexity to achieve the same end results. Adding unnecessary
complexity to the protocol will more likely lead the protocol to the
dustbin of protocols that never get adopted because they are just too
complex to implement and/or troubleshoot.

While it may be possible to design a protocol to satisfy every single
intermediate network topology, it will not be without the cost of
additional complexity. Instead we must design the protocol in such a way
that it satisfies most commonly encountered topologies and leave the
rest to vendor innovation to deal with the corner cases. 

Thanks
partha

> From: Scott G Kelly [mailto:[email-masked]]
> Sent: Sunday, June 04, 2006 11:32 AM
> To: Bob O'Hara (boohara)
> Cc: [email-masked]
> Bob O'Hara (boohara) wrote:
> > Abhijit,
> >
> > I apologize if my original reply seemed to dismiss all of your
> > proposals.  I was addressing only the first proposal that was to
> > replace the "shim" header with a CAPWAP header and still run over a
> > single UDP port.
> 
> I think we need to correct a potential misperception, that being that
> what is being proposed is kludgy, a "shim", and therefore worthy of
> denigration.  This has no technical justification - and it's what I've
> been referring to as misdirection, because it tends to evoke a
> pejorative interpretation which is neither technically justified nor
> appropriate.
> 
> CAPWAP is a single protocol which currently supports three classes of
> protocol data unit (PDU): discovery, control, and data. The proposed
> de-multiplexing mechanism is simply a PDU type field. We have ample
> precedence for the use of such PDU type fields in other widely
deployed
> protocols such as tls, snmp, l2tp, pptp, and yes, even lwapp (where
the
> 'c' bit serves this function). Layered protocols are quite common in
> the Internet today.
> 
> Existing routers and switches have no difficulty in handling these
> widely deployed protocols, perhaps because they have no mandate other
> than to route and or switch the traffic. In particular, there has
never
> been a general IETF protocol design requirement for routers and
> switches to be able to perform economy packet classication via tcp/udp
> ports - if there were, all protocols would be tcp/udp-based, and all
of
> the various protocols' PDU's would be similarly decomposed by port.
But
> they aren't.
> 
> Reiterating my earlier observation, backward compatibility with a
> particular vendor's legacy network gear in terms of identifying capwap
> internals is not a stated goal of this working group, nor should it
be.
> It's not in the objectives draft, the architectural taxonomy, or the
> working group charter. It is not a requirement. And it's not in the
> common interest of the broader community - vendors *or* customers.
> 
> --Scott
>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 6 Jun 2006 07:07:43 -0700

Scott G Kelly [mailto:[email-masked]] says:
> a single capwap protocol also requires "NO CHANGE TO EXISTING 
> NETWORK INFRASTRUCTURE EQUIPMENT". 
Working for a manufacturer that happens to build a significant
amount of network infrastructure, and that have a rather large
customer base that use both wired, and wireless, products, I
will once more state that I completely disagree with you. 

> As for the balance of this post, I didn't respond to Chris' 
> email because there's nothing material to our discussion 
> there.
I've provided you with countless examples, as have others, some
such as Chris that actually have to build and run networks, 
but these views have been consistently waved aside by you 
as being irrelevant. At this point I will once more state that
I completely disagree with your views, and leave it at that.

We clearly don't have rough concensus on this point. Not sure
how to move forward.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems