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

[Pasi.Eronen (Pasi.Eronen]

Pat Calhoun wrote:

> > > > 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...)
> 
> Yes, you are correct that bridges work this way, but this is not a
> use case we are trying to address in this working group. An access
> point uses the IEEE 802.11 primitives for populating its learning
> table (e.g., association request), while a bridge needs to use other
> means (e.g., spanning tree). Trying to add wireless bridges to this
> specification would not only expand the scope of the WG and
> protocol, but would require lots more work.

Large bridges are indeed different, but small "wireless bridges" are
marketed for e.g. connecting a printer with wired Ethernet jack
to office WLAN.

Does this mean if the office WLAN switches to CAPWAP-based access
points, and uses split MAC with 802.3 frames, those would stop
working? 

(I don't think there's a need to expand the scope of the WG --
accurately documenting what parts of 802.11 don't 100% work
with CAPWAP is IMHO quite sufficient.)

<snip>

> > > > 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.
> 
> OK, fair enough. That is one exception, but that one is 
> described in the spec. The spec even includes:
> 
> <current text>
> 2.2.1.  Split MAC
> [...]
> 
>    o  The WTP generates the IEEE 802.11 Beacon frames, using 
>       information
>       provided to it through the IEEE 802.11 Add WLAN (see 
>       Section 6.1)
>       message element, including the RSNIE, which indicates support of
>       802.1X and AES-CCMP.
> </current text>

Yes, but the spec isn't very clear on how the RSN IE exactly is
processed by the WTP (the IE has number of different fields).

> > 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?
> 
> OK, that should have been Power Constraint, not Power
> Capability. Thanks for finding that one.

Ok, that clarifies this part...

> > > 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).
> 
> Actually, re-reading the spec, I don't see where it dictates that
> the WTP needs to process IEs. It does mention that the WTP needs to
> look at the Result-Code in the (re-)Association Response. It also
> does mention that the AC MAY send a Disassocation Request to the
> station, through the WTP, and that the WTP should take the
> Disassocation Request as an indication that service for the station
> is to be terminated.
> 
> Otherwise, there are no IE processing requirements.

Again, except for the RSN IE, whose processing is mentioned,
but not described in detail.

Best regards,
Pasi