Subject: RE: [Capwap] Taxonomy Recommendations

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Thu, 16 Jun 2005 08:53:51 -0400

All,

Let me start by saying that I agree with the authors conclusion that the
protocol could / should support Local and Split MAC arch. However in my
opinion the group should refrain from artificially articulate
functionality-restriction around these two architectures buckets and
avoid dive into a theoretical debate whether function X resides in the
WTP or AC in each arch.

I believe we better concentrate on dividing the functionality between AC
and WTP and provide a mechanism for the AC to chose (based on WTP
capabilities and operator commands) and instruct the WTP accordingly.

Take for example the IS service: where it fits in Slit and Local - WTP
or AC? I would disagree the authors conclusion (section 5 first bullet)
w.r.t. bridging function, and believes we can, and should, allow the
operator to chose.

Since the spectrum of functionalities were outlined by APF SG and
Taxonomy draft I would say we need to reach a consensus which
functionality can be implemented at the AC and WTP (e.g. Integration
Service) and which should solely reside at the AC( e.g. WTP Firmware or
802.1x authenticator). 
If dependences among different functionalities are identified (what lead
to Split vs. Local MAC arch in the first place) then, in my opinion,
they need to be documented and impose restriction on customer
configuration.

Regards,
Emek

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pat Calhoun
Sent: Wednesday, June 15, 2005 3:17 PM
To: [email-masked]
Subject: RE: [Capwap] Taxonomy Recommendations

All,

I wanted to follow up on the draft that was sent last week, and explain
some of the justification for this draft. 

When Inderpreet (co-author of the CAPWAP CTP submission), Bob O'Hara and
I (co-authors of the CAPWAP LWAPP submission) discussed the differences
between our respective approaches, it became clear that we did not have
agreement on the definitions of Local and Split MAC. In re-reading the
taxonomy specification, it became clear that while the taxonomy document
lists the various approaches surveyed, it really did not provide a
conclusion or recommendation. Therefore, the reader is left with no
clear understanding the CAPWAP Working Group's definition of these two
approaches.

For instance, by following the letter of the taxonomy specification, one
will observe that the split in functionality varies greatly from one
implementation of Local MAC to another. The following is figure 9, taken
directly from the document:

                   Arch7   Arch8   Arch9   Arch10   Arch11
                   -----   -----   -----   ------   ------

      Distribution
      Service       AC     AC       WTP      AC      WTP

      Integration
      Service       WTP    WTP      WTP      WTP     WTP

      Beacon
      Generation    WTP    WTP      WTP      WTP     WTP

      Probe
      Response      WTP    WTP      WTP      WTP     WTP

      Power mgmt
      Packet
      Buffering     WTP    WTP      WTP      WTP     WTP

      Fragmentation/
      Defragment.   WTP    WTP      WTP      WTP     WTP

      Association
      Disassoc.
      Reassociation AC     WTP      WTP      WTP     WTP

      WME/11e
      --------------
      classifying   AC                               WTP

      scheduling    WTP    AC/WTP   WTP      WTP     WTP

      queuing       WTP             WTP      WTP     WTP

      Authentication
      and Privacy
      --------------
      802.1x/EAP    AC      AC      AC/WTP   AC       AC/WTP

      Keys
      Management    AC      AC      WTP      AC       AC

      802.11
      Encryption/
      Decryption    WTP     WTP     WTP      WTP      WTP

    Figure 9: Mapping of 802.11 Functions for Local MAC Architecture

Finally, the secion on Local MAC concludes with the following text:

   From Figure 7, Figure 8 and Figure 9, it is clear that differences
   among vendors in the Local MAC Architecture are relatively minor, and
   most of the functional mapping appears to be common across vendors.

The issue with the above paragraph is that while the differences are
restricted to specific functions (e.g., Distribution Service), these
small differences will significantly change how products operate. In the
case of Distribution Service, it will state whether traffic is tunneled
to/from the WTP or not.

Given the above, Inderpreet, Bob and I collaborated together in order to
come to some agreement on what the differences between both approaches
were.
I think that the results of our extensive conversations resulted in the
previously mentioned draft. I would urge the WG to take a look at this
document and provide comments. At a minimum, we believe it would be in
the best interest of the working group to at least discuss whether the
taxonomy document is in need of some conclusions in order to set a frame
of reference in the two main approaches.

Thanks,

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Pat Calhoun
> Sent: Thursday, June 09, 2005 2:28 PM
> To: [email-masked]
> Subject: [Capwap] Taxonomy Recommendations
> 
> All,
>  
> I wanted to announce the early availability of the CAPWAP taxonomy 
> recommendation draft that Bob O'Hara Inderpreet Singh and I have been 
> working on. It can be found at 
> http://www.capwap.org/draft-calhoun-capwap-taxonomy-recommenda
> tion-00.txt.
> 
> 
> Abstract
> 
>    The IETF's CAPWAP working group has documented various product
>    architectures and has categorized the Centralized WLAN 
> Architectures
>    into two main buckets: Split and Local MAC.  While the document
>    contains very relevant and useful information, what it does is list
>    the architectural variants of these two buckets, but does not
>    unambiguously define either the Split MAC or Local MAC 
> architectures.
>    In order for CAPWAP to be successful, it is crucial for the 
> protocol
>    evaluation team, and the working group, to agree on unambiguous
>    terminology to describe these architectures.
> 
>    This document proposes terminology to unambiguously describe the
>    relevant architectures found in the taxonomy document, for the
>    purpose of initiating a discussion within the working group and to
>    allow the protocol evaluation work to come to a fruitful 
> conclusion.
>    We conclude in this document that the architectures are very 
> similar
>    and could be supported via a single protocol.
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit Cisco Systems
> 
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: "Pat Calhoun" <[email-masked]>
Date: Thu, 16 Jun 2005 07:01:34 -0700

To address your one comment:

"However in my opinion the group should refrain from artificially articulate
functionality-restriction around these two architectures buckets and avoid
dive into a theoretical debate whether function X resides in the WTP or AC
in each arch."

I respectfully disagree. I believe that the only way that we can guarantee
interoperability is by providing very clear guidelines, and not allow a
checkboard approach where either the WTP or the AC can fulfill a function as
it deems necessary.

I believe that the alternative that you are proposing would take a
considerable amount of time to get right, and would unnecessarily complicate
the protocol. Let's define Split and Local and define a protocol that can
address both.

Pat Calhoun

> From: Sadot, Emek (Emek) [mailto:[email-masked]] 
> Sent: Thursday, June 16, 2005 5:54 AM
> To: Pat Calhoun; [email-masked]
> Let me start by saying that I agree with the authors 
> conclusion that the protocol could / should support Local and 
> Split MAC arch. However in my opinion the group should 
> refrain from artificially articulate 
> functionality-restriction around these two architectures 
> buckets and avoid dive into a theoretical debate whether 
> function X resides in the WTP or AC in each arch.
> 
> I believe we better concentrate on dividing the functionality 
> between AC and WTP and provide a mechanism for the AC to 
> chose (based on WTP capabilities and operator commands) and 
> instruct the WTP accordingly.
> 
> Take for example the IS service: where it fits in Slit and 
> Local - WTP or AC? I would disagree the authors conclusion 
> (section 5 first bullet) w.r.t. bridging function, and 
> believes we can, and should, allow the operator to chose.
> 
> Since the spectrum of functionalities were outlined by APF SG 
> and Taxonomy draft I would say we need to reach a consensus 
> which functionality can be implemented at the AC and WTP 
> (e.g. Integration
> Service) and which should solely reside at the AC( e.g. WTP 
> Firmware or 802.1x authenticator). 
> If dependences among different functionalities are identified 
> (what lead to Split vs. Local MAC arch in the first place) 
> then, in my opinion, they need to be documented and impose 
> restriction on customer configuration.
> 
> Regards,
> Emek
> 
> I wanted to follow up on the draft that was sent last week, 
> and explain some of the justification for this draft. 
> 
> When Inderpreet (co-author of the CAPWAP CTP submission), Bob 
> O'Hara and I (co-authors of the CAPWAP LWAPP submission) 
> discussed the differences between our respective approaches, 
> it became clear that we did not have agreement on the 
> definitions of Local and Split MAC. In re-reading the 
> taxonomy specification, it became clear that while the 
> taxonomy document lists the various approaches surveyed, it 
> really did not provide a conclusion or recommendation. 
> Therefore, the reader is left with no clear understanding the 
> CAPWAP Working Group's definition of these two approaches.
> 
> For instance, by following the letter of the taxonomy 
> specification, one will observe that the split in 
> functionality varies greatly from one implementation of Local 
> MAC to another. The following is figure 9, taken directly 
> from the document:
> 
> The issue with the above paragraph is that while the 
> differences are restricted to specific functions (e.g., 
> Distribution Service), these small differences will 
> significantly change how products operate. In the case of 
> Distribution Service, it will state whether traffic is 
> tunneled to/from the WTP or not.
> 
> Given the above, Inderpreet, Bob and I collaborated together 
> in order to come to some agreement on what the differences 
> between both approaches were.
> I think that the results of our extensive conversations 
> resulted in the previously mentioned draft. I would urge the 
> WG to take a look at this document and provide comments. At a 
> minimum, we believe it would be in the best interest of the 
> working group to at least discuss whether the taxonomy 
> document is in need of some conclusions in order to set a 
> frame of reference in the two main approaches.
> 
> Thanks,
> 
> Pat Calhoun

---

From: "James Kempf" <[email-masked]>
Date: Mon, 20 Jun 2005 10:21:50 -0700

Emek,

jak>> OK, so what criteria would cause an operator to choose bridging at the
WTP versus bridging at the AC?

        jak