Subject: Re: [Capwap] Reserved bits and fields

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 28 Aug 2006 12:58:37 -0700

Issue 209 created

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Monday, August 28, 2006 11:53 AM
> To: [email-masked]
> Subject: Re: [Capwap] Reserved bits and fields
> 
> Bob O'Hara writes...
> 
> > Yes, I still believe that there needs to be a specification for the 
> > receiver to ignore any value received in the reserved bits and
> fields..
> 
> I agree.  Requiring the receiver to ignore reserved fields, 
> assuming that the protocol version number unambiguously 
> defines which bits in which fields are reserved, is good 
> design practice.
> 
> I don't think that this eliminates the requirement for the 
> sender to "zero" all reserved bits, however, as that is also 
> good design practice.
> 
> Be conservative in what you send and liberal in what you receive.
> 
> _________________________________________________________________
> 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: "Puneet Agarwal" <[email-masked]>
Date: Wed, 30 Aug 2006 14:20:31 -0700

Hi All,

I read through the -02 spec and had following questions. I would
appreciate if the author or others could help clarify.

Thanks.

-Puneet
******************************************

1) Section 11.1.1 Split MAC
  " All client data frames are tunneled between the WTP and the AC."

  It is unclear what is meant by Client Data Frames - is it only
  802.11 data Frames or does it include 802.11 Management/Control Frames
also?

2) In Split MAC, are 802.11 Management Frames sent in CAPWAP data
frames?

3) If (2) is true (ignore otherwise), then what is the CAPWAP priority
of
these frames?

4) In Fig 5, "Split MAC Message Flow", why is the "Probe Request" from
the
Client sent to the AC also - even though all the processing was done at
the WTP
for this message?

5) In Fig 5, what is the semantics of the notation:
"Add Mobile (Clear Text, 802.1X)"?
I could not find the 2 parameters implied by "Clear Text" and "802.1X"
in the
description of Add Mobile in section 4.4.8 or in section 11.9.9
(IEEE 802.11 Mobile).

6) Section 11.9.9: "If the QoS field is set," - which field (where) are
you
checking for the presence or absence of the Qos Field?

7) Radio ID, WLAN ID, BSSID - is there an implied relationship between
these
various configured element ie many radios to one WLAN ID etc.

8) Assoc ID vs MAC Addr for id (which takes precedence or do you need to
do
both checks)

9) Section 11.5: Please state clearly that even though these are 802.11
Control Messages, they are still sent in CAPWAP DATA messages (at least
for
now). 

10) What is the recommendation for 802.1P and DSCP values for 802.11
Data
    Frames? Do you honor the .11 QoS semantics between WTP and AC or are
all
    .11 Data Frames sent at the same priority in CAPWAP?

11) Should 802.1X frames be sent with different QoS than regular 802.11
Data
Frames? What is our QoS Philosophy for such control traffic?

12) It seems that within CAPWAP Data channel, there are multiple 802.11
control
channels (it seems that different QoS levels are an implicit attempt at
this
- refer to section 11.5).
General question to the group: Would it be beneficial to transport these
.11 control channels as "raw" data channels in CAPWAP Control messages
allowing
the network to honor the 8 .1p priorities for 802.11 Data frames in the
CAPWAP
DATA message.

13) Section 11.1.2 Local MAC: The spec defines capability to tunnel
Client
data frames as 802.3 frames between the WTP and the AC. It would seem
that
the CAPWAP Data tunnel (as currently defined) would need to carry both
802.3
payload (for client data frames) and 802.11 payload (for RSNA Key Mgmnt
frames). Is this capability really desired?

14) Section 4.1 CAPWAP Transport Header - It seems that this section
should be
renamed "CAPWAP Header" or all references in section 4 and other places
should
be updated to be "CAPWAP Transport Header".

15) Section 4.1: The RID field here is 5 bits while in all control
messages it
seems to be 8 bits - this needs to be reconciled

16) Section 4.1: Description of RID field is unclear especially:

" WTPs with multiple radios but a single MAC Address range
      use this field to indicate which radio is associated with the
      packet."

It would be great if this could be clarified - it seems to be implying
that
this is  used to support the case where multiple radios share the same
Radio
MAC address but is not very clear - is this the case?

17) Section 4.1:  I assume that implementations MUST support 802.3
frames as
well as "Native" frames in the same CAPWAP Data Tunnel. Is this true and
is
that what we really want?

18) Section 4.1: M bit. You mention in the text that "this field MUST
NOT be
set to one in pkts sent by the AC to the WTP".

However, when you are transporting 802.3 frames, won't the AC need to
indicate
 to the WTP what BSSID to use when sending the frame (or is it assumed
that
 the BSSID is derived from the dest Client's MAC Addr for unicast)?

19) Section 11.9.1: For Tunnel Mode == "802.3 tunnel" in Local MAC mode,
how
are RSNA frames converted to 802.3 as they seem to be required for Local
Mac

20) In Local MAC with 802.3 tunnel, how are 4 MAC 802.11 converted to
802.3
without loss of info? Ie do we need to define TX-MAC element also (in
CAPWAP
data frames from WTP to AC)?

21) In Split MAC Mode: when the WTP does encryption/decryption, please
specify
the exact fields that are valid when WTP sends such frames to the AC (as
they
are now pseudo-802.11 frames after potential 802.11 reassembly in the
WTP).

22) Can the same WLAN ID be assigned to different radios with the same
BSSID?

23) Can the same WLAN ID be assigned to different radios with different
BSSID?

24) For multicast pkts, does AC need to send multiple copies of the
packet to
send to each radio on the WTP that is part of the same WLAN ID or is the
packet replicated by the WTP to all radios that are part of the same
WLAN ID?

25) Local MAC with local bridge is the default mode - this implies that
all
implementations must support this config (which has the most complex s/w
for
the AP) - is that the correct default and why was it chosen - should
this be
changed?

26) Why is the MAC mode and Tunnel Mode part of the WLANID config? What
is the
practical reason for allowing this per WLANID?

27) How does multicast handle the case when the number of WLANIDs is
greater
than 16 - how does AC indicate that to the WTP? It seems you run out of
bits
in the CAPWAP data packets.