Subject: [OPSAWG] Seeking comments on draft "IEEE 802.11 MAC Profile for CAPWAP"

From: "Rajesh Pazhyannur (rpazhyan)" <[email-masked]>
Date: Mon, 14 Oct 2013 14:46:17 +0000

Greetings...

We have submitted a new version of the draft (previously titled "Hybrid MAC-Model for CAPWAP".
While solving the same problem as in the original draft, this takes a different approach. We introduce a new element IEEE 802.11 MAC Profile. This profile defines the functional split between the MAC and AC.  The idea of using profiles was based on discussion in the last working groups meeting as well as offline meetings with other participants. While somewhat similar to mode defined in RFC 5416, this solves the problem with the ambiguity in the mode definitions in RFC 5416 as well as enables different functional splits to be defined in the future. The link to the draft is https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac

We are soliciting comments and feedback.

Thanks

Regards

Rajesh

---

From: Dorothy Stanley <[email-masked]>
Date: Mon, 28 Oct 2013 10:29:43 -0700

Hi Rajesh,

Comments below.

Dorothy
-------------
1.       Today, Split and Local MAC are negotiated using the WTP MAC Type
message element. There is no need to include Local and Split MAC in the
profile element. The new mode is actually a profile of the current defined
Split MAC. In section 4, delete 0 and 1, renumber “2” to “0” and change
from “indentified” to “identified” in the line above.
Section 3.2 can be deleted, and Sections 3.1 and 3.3 combined into a single
table.
2.      Section 3.3.1: “Frames Exchange” to “Frame Exchange”
3.       Section 4, “The IEEE 802.11 WTP Profile message element allows the
WTP to communicate the profile*(s)* it supports to the AC.”

4.       4. The new MAC model is named “Hybrid MAC profile”. This name is
very general, and the description says that it is a specific profile of the
split MAC, not a hybrid (as the current name suggests) of split and local.”
Suggest renaming “Hybrid MAC” to “Split MAC with WTP Encryption” (or
similar)

5.       5. Section 5. The text is not clear: “it could directly
reference”. Well it could, Make it reference the section or not.
Change to “There are no additional security considerations introduced by
this specification in addition to those in [RFC5416].

6.       6. Section 4 – add a period at the end of the first sentence after
“one such message element”.

7.       7. Abstract. Suggested edits below:

The CAPWAP protocol defines two modes of operation for IEEE 802.11

   WTPs: Split and Local MAC (medium access control), as described in

   [RFC5415], *and* [RFC5416].  Specifically, [RFC5416] describes in detail the

   division of labor *functionality *between *the *WTP and AC in *both
*the Split and Local MAC

   modes.  Unfortunately, *tT**here* are many *some *functions that have not yet

   been clearly defined whether they belong *can be performed in
either *to the WTP or the AC.  For

   example*, in the Split MAC mode, * IEEE 802.11 encryption is
specified as located in either in

   the AC or the WTP with no clear way to negotiate where it should be

   located.  This lack of specification leads to interoperability *issues*

   between *an *AC and WTP when *the *AC and WTP come from different
vendors.  To

   solve this problem, this specification defines *a profile of the
Split MAC mode, “Split MAC with WTP Encryption” mode of operation and
an* the concept of IEEE

   802.11 MAC profile *message element used to negotiate the profile.
*where each profile refers to a table containing an

   unambigous division of labor between WTP and AC.  The *IEEE 802.11
MAC *profile *message element* is used

   as follows: the WTP informs the AC of the supported *profile(s*) and the

   AC selects the profile when it configures to be configured on the WTP.

On Mon, Oct 14, 2013 at 7:46 AM, Rajesh Pazhyannur (rpazhyan) <
[email-masked]> wrote:

>  Greetings…
>
> We have submitted a new version of the draft (previously titled “Hybrid
> MAC-Model for CAPWAP”.
> While solving the same problem as in the original draft, this takes a
> different approach. We introduce a new element IEEE 802.11 MAC Profile.
> This profile defines the functional split between the MAC and AC.  The idea
> of using profiles was based on discussion in the last working groups
> meeting as well as offline meetings with other participants. While somewhat
> similar to mode defined in RFC 5416, this solves the problem with the
> ambiguity in the mode definitions in RFC 5416 as well as enables different
> functional splits to be defined in the future. The link to the draft is *
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac*<https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac>
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>
>