Capwap Mailing List: Re: Last call comments for capwap-protocol-binding-ieee80211-07

[Pasi.Eronen (Pasi.Eronen]

Pat Calhoun wrote:

> > I was under the impression that 802 (or at least 802.11) required
> > (or assumed) strict in-order delivery -- but perhaps I remember
> > this wrong?  (Obvious, tunneling over arbitrary IP hops doesn't
> > guarantee in-order delivery, and it seems the data channel doesn't
> > have mechanisms to reorder or drop out-of-order packets.)

> The MAC layer will provide guaranteed delivery at the AP, but
> remember that the air isn't exactly a reliable medium. The AP is
> then responsible for tunneling the packets. For open or when crypto
> is provided at the WTP, there are no issues with re-ordering. When
> crypto is provided at the AC, both TKIP and AES have no ordering
> requirements, so that is also not an issue.

IEEE 802.11 spec talks about the possibility that the higher layer
protocol (run on top of 802?) would require in-order delivery (IP
doesn't, of course), and seems to be able to provide strict in-order
delivery.

It might be at least good to discuss this topic in the spec
(describing that CAPWAP might not be able to provide fully faithful
802.11 implementation in Split MAC mode, but that this doesn't matter
for most practical purposes when you're running TCP/IP).

> > 802.11 header has 4 different addresses, all of which can be
> > different.  When doing split MAC with 802.3 frames, the 802.3
> > frame contains only two of the addresses; the "Radio MAC Address"
> > field in CAPWAP header contains the third -- but what about the
> > fourth one?

> The CAPWAP WG only supports 802.11-2007, and does not support ad-hoc
> mode (client-client). The very fact that we are providing an
> alternative way to deploy 802.11 infrastructure means that do not
> need to support ad hoc mode ;-)

I wasn't thinking about ad-hoc mode, but rather a STA sending a packet
to an AP where the 802.3 source address would be different from the
transmitting STA address.  Is this possible? (Perhaps a "wireless
Ethernet bridge", which connects to PC via wired Ethernet, but looks
like STA to the AP? Although I'm not quite sure how the address fields
really look in this situation...)

> > The document should have some more text about how the WTP
> > processes IEEE 802.11 IEs it receives from the AC. Section 6.6
> > talks about copying them to Beacon/Probe Response messages, but it
> > seems that in some cases, the WTP also does some local
> > processing. (I was sort of expecting a list of all IEs, and
> > description of expected WTP processing (possibly none) for them.)

> There are two mode of operation:
> 1. Split MAC. In this case, the WTP needs to make sure that 
> the beacons have the proper information. Other than that,the AC 
> handles all of the IEs in the manner described in the 802.11-2007 
> standard.

This is contradicted by text in e.g. Section 6.15, which requires the
WTP to process (beyond copying to beacons) the IE received from AC
even in Split MAC mode.

Also, it seems that some of the IEs sent are not even included in
beacons; e.g. Section 6.1 says the AC MUST send the Power Capability
IE to the WTP -- but reading 802.11, I can't seem to find any place
the AP would actually send this IE (it's sent by the STA). So what
does the WTP do with it?

> 2. Local MAC. In this case, the 802.11 management packets are
> processed in the WTP, as described 2.2.2. In this case, the WTP
> handles the IEs in the manner described in the 802.11-2007 standard.

Right, 802.11-2007 specifies how the WTP processes IEs received
from the STA. But it doesn't specify how to process IEs received from
AC (obviously, since the concept of AC doesn't exist).

> > Section 6.15: Is this really the PTK (which also includes KCK and
> > KEK, which aren't needed by the WTP since the AC is handling the
> > EAPOL-Key messages -- so probably shouldn't be sent to PTK), or
> > only the TK used for encrypting traffic?
>
> We send the whole PTK. The WTP simply extracts what it needs and uses
> it.

In that case, the "key the WTP is to use when encrypting traffic to/from
the station" is a bit confusing -- that would only the TK.

> > Is the binding specified here sufficient for 802.11r as well, or
> > would something more be needed? (I don't know the answer -- but
> > probably the document should tell what it is)

> Given we only support 802.11-2007, we do not worry about 802.11r at
> this point (or 802.11n), so the answer is yes, more is needed.

The document certainly gives the impression of supporting 802.11n,
since it's e.g. listed in WTP Radio Information message element.
If that's not the case, it'd be useful to say explicitly that
more is needed for 11r and 11n.


Best regards,
Pasi