Subject: RE: [Capwap] Taxonomy Recommendations

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Wed, 15 Jun 2005 12:14:11 -0600

Thanks for the joint effort (by authors of two candidate protocols for
eval. as I see it) in making a case for clarification of terminology.

If the changes and clarifications proposed are extensive - comments in
form of I-D is useful to place-hold them.

The WG should (especially the original taxonomy team authors) comment on
these comments (draft): WG has approved the -06 version of the taxonomy
draft. Two of the authors are in this as well :)

It is also important to understand the implications, if any, (on
Objectives draft) if WG agrees to any of the proposed clarifications. It
may turn out to be transparent to the Objectives draft. This needs to
happen soon for Objectives to freeze and let the evaluation team use a
baselined version.

[BTW: the taxonomy draft is in RFC editor's queue - actually just
completed AUTH48].

-mani
======
-----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-recommendation-00.tx
t.

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

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Mon, 20 Jun 2005 13:48:22 -0600

Jim,

I can't agree more on the first paragraph. That is actually at the heart
of standardization challenge for CAPWAP protocol.

More inline...

-mani
======
-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Monday, June 20, 2005 10:46 AM
To: Mani, Mahalingam (Mahalingam); Yang, Lily L; Pat Calhoun
Cc: [email-masked]
Subject: Re: [Capwap] Taxonomy Recommendations

Mani,

I think the basic problem here is that the taxonomy draft discusses
functional architecture and existing network reference architectures but
even though the network reference architectures in the different
existing
products are different and in some cased conflicting, the taxonomy draft
doesn't really point out where there is a conflict because, as Lily
said,
that wasn't a goal of the draft. The grouping of functional entities
into
network entities (i.e. boxes) in the network reference architecture is
what
defines which interfaces between functional entities are instantiated as
protocols and which are instantiated as APIs within a box. If CAPWAP is
ever
to develop a standardized, interoperable protocol, there must be a clear
and
precise understanding and agreement on where these interfaces are. Pat
and
Inderpreet's draft discuss a couple of issues around this but doesn't
really
get to the heart of the problem.

For example, taking the issue of where the distribution function lies,
if
the distribution function is placed in the WTP, then bridging is an API
within the WTP box. If the distribution function is placed in the AC,
then
there is need for a protocol across the WTP/AC interface to tunnel
802.11
data frames to the AC.

Part of the problem is that the taxonomy draft renamed the AP without

[Mani, Mahalingam (Mahalingam)] 
[Mani, Mahalingam (Mahalingam)] I agree it did do a name-change to
distinguish the in split & local manifestations; the primary point - as
I had stated earlier - and is now the active discussion; is with split &
local AP itself (leave alone split-MAC); I disagree that was the only
outcome - the draft went on to characterize WTP in these manifestations.
Sure - enough within the scope of the taxonomy; not asserting to nail
down one split behavior.

changing really what it is. Both the AP and WTP are network entities and
not
functional entities.

The other, major part of the problem, as you outline below, is that the
IEEE
has refused to commit to a network reference architecture. They have
only
committed to a functional architecture. Exactly what the interfaces are
between network entities and therefore where standardized protocols are
required is therefore not specified. Different vendors have taken their
own
cut at this, so there are now multiple network reference architectural
variants in the market. Not suprisingly, vendors are not going to agree
to a

[Mani, Mahalingam (Mahalingam)] 
[Mani, Mahalingam (Mahalingam)] either they disagree or agree on a way
to get over this - protocol-wise or otherwise. If it is the former - we
all have been burying our heads in the sand - knowing well this is
coming anyway.

[Mani] It is again going back to the recharter-phase discussions late
last year (of separating and defining cleanly the control aspects -
which is what should constitute the CAPWAP - while specifying how
control impacts the dataplane and where it should be
controlled/terminated) without specifying how the dataplane itself
(tunneled/forwarded/terminated paths etc.).

[mani] While it does not solve all the issues right away it paves way
for a better perspective of what RFC3990 wants addressed; and allows for
a better chance to articulate a protocol that solves the customer pains
(of managing & controlling small & large deployments securely).

[Mani] The AC, viewed as logically separate entity from the
WLAN-switch/controller-box, can set the stage for architectural
description of how and where to control the WTP and wherever the DS
(dist. Services)-exit is.

particular network reference architecture if it means that their
products
will have protocol-requiring interfaces on the wrong side of the split.
So,

[Mani, Mahalingam (Mahalingam)] it may be - we already made a start in
taxonomy by at least allowing for two variants to exist and agreeing on
WG recharter out of conviction to make this level of flexibility
realizable in the protocol.

I think it will be very hard to achieve concensus on this, though I
think it
might help to start with defining what network reference architectural
variants lead to what protocol interfaces. I think Pat and Inderpreet's
draft does make a good start at the latter, though not in as formal a
way as
I've seen in past architectural studies.
[Mani, Mahalingam (Mahalingam)] 
[Mani, Mahalingam (Mahalingam)] fortunately we made forward progress as
WG - albeit doing mere taxonomy work (Bob at that time rightly mentioned
we are documenting - or some such equivalent - not doing architecture).
Unfortunately it was at the expense of having to sacrifice architectural
analysis (which is what we did during the 2nd & 3rd BoFs) - which may be
resurrecting now.

            jak

----- Original Message ----- 
From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
To: "Yang, Lily L" <[email-masked]>; "Pat Calhoun"
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 16, 2005 7:13 AM
Subject: RE: [Capwap] Taxonomy Recommendations

I have no objections to this 'bug-fix' if it can happen in time and has
no author/WG objections. We can request the RFC Ed. to hold off.

As for the other issue on split-MAC interpretation:
The split-discussion is long overdue; and is worth having - to help
evaluation as well. I think resolution of the discussion is important to
arrive at the best approach to CAPWAP protocol accommodating/not split
variants.

History:
We had clearly noted not to make any recommendations on what a split
characteristic must be in the taxonomy. This has perhaps been argued
many times in (taxonomy) design team and in IETF58-62 as well. There was
no scope for us in the then charter to venture that way.

When APF AHC initially started its work - the hope was it would offer
enough information for CAPWAP to draw conclusions for future work; there
were no expectations on what they would recommend the split ought to be
once they were chartered (there were hopes much prior to that). Inasmuch
as IEEE 802.11 endorsed and acknowledged the documented splits caused no
standards departure/breakage in implementation or behavior - by its
review of the taxonomy draft - we had validated all architectures from
IEEE 802.11 perspective.

It was clear when APF AHC group was formed that it will transpire to
provide only clarifying interpretations of functions - not delineate or
standardize splits.

-mani
======
-----Original Message-----
From: Yang, Lily L [mailto:[email-masked]]
Sent: Wednesday, June 15, 2005 1:19 PM
To: Mani, Mahalingam (Mahalingam); Pat Calhoun
Cc: [email-masked]
Subject: RE: [Capwap] Taxonomy Recommendations

Hi, Pat and Mani --

I have not read through the entire Taxonomy Recommendations document
yet, but just reading through the first few pages, I believe the authors
are correct in pointing out one of the "inconsistency" (error) in the
taxonomy draft. There was a paragraph in the taxonomy draft Section 5.6:
" The commonalities and differences between Local MAC and Split MAC are
   most clearly seen by comparing Figure 7 to Figure 10.  The
   commonality is that 802.11 control frames are terminated at WTPs in
   both cases.  The main difference between Local MAC and Split MAC is
   that the WTP terminates only the 802.11 control frames in the Split
   MAC, while the WTP may terminate all 802.11 frames in the Local MAC.
   An interesting consequence of this difference is that the Integration
   Service, which essentially refers to bridging between 802.11 and
   802.3 frames, is implemented by the AC in the Split MAC, but can be
   part of either the AC or WTP in the Local MAC."
The last sentence, as pointed out by Pat, Bob and Inderpreet's document,
was incorrect. According to Figure 9, Integration Service, for all the
parties classified as Local MAC, is implemented by WTP.
Given that we still have about 3 hours remaining in the authors' 48 hour
window, I would like to send a note to RFC Editor suggesting the
following sentence to replace the last sentence in the paragraph:
"An interesting consequence of this difference is that the Integration
   Service, which essentially refers to bridging between 802.11 and
   802.3 frames, is implemented by the AC in the Split MAC and by the
WTP in the Local MAC, as shown in Figure 9 and Figure 12."

Glaring as it is, I believe this error does not carry any far reaching
implication to the entire document and hence it is bug we can fix right
now.

Regarding the comment from the authors that taxonomy draft lacks
conclusion and recommendation and hence the motivation to take it
further to clearly define what Local and Split MAC really mean in terms
of functional split -- I think that is a fair comment -- Personally I
was tempted to take that step in the taxonomy draft with the intention
to help the WG moving forward, but as the editor of the draft, I
received clear instruction from the chairs and the WG that a taxonomy
only goes so far to "document" the reality of the market, not to
"define" any architectures. So the draft deliberately didn't go far into
making any specific functional split recommendation.

As I advocated in both July and Nov IETF meeting last year, I believe
there is indeed a gap between taxonomy draft and objective draft -- the
WG needs a clear definition of the functional split for Local,
especially Split MAC, but that is not the charter of either taxonomy
draft or Objective draft. Some people have the illusion that IEEE 802.11
(specifically the APF ad hoc group) will provide such definition. The
clear answer there is NO, IEEE would not do that. It is up to us in this
group to agree on the split and move on. So if indeed this Taxonomy
Recommendation draft fulfills this purpose, I personally believe it is a
very necessary step to take in order to move forward. However, as I
said, I have not reviewed the entire document yet and so I would reserve
until then to offer any further comments.

But I do want to fix the error in Section 5.6 in Taxonomy draft NOW.

Lily
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mani, Mahalingam (Mahalingam)
Sent: Wednesday, June 15, 2005 11:14 AM
To: Pat Calhoun; [email-masked]
Subject: RE: [Capwap] Taxonomy Recommendations

-mani
======
-----Original Message-----

All,

Abstract

Pat Calhoun

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Tue, 28 Jun 2005 02:14:12 -0400

James,

Please see inline.

Emek 

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Tuesday, June 21, 2005 7:34 PM
To: Sadot, Emek (Emek); Pat Calhoun; [email-masked]
Subject: Re: [Capwap] Taxonomy Recommendations

Emek,

The main reason I see to bridge frames at the WTP is to keep session's
shortest path (diminish delay, latency, jitter, etc., for real-time
application such as VoWLAN). For example: AC at NYC and WTP located at
London; London office has two or three legs to the external world: (a)
VPN/FR/Lease line to NYC main office, (b) local PSTN link and (c) local
Internet service / exist to local ISP. Wi-Fi voice call from London
office better not be traveled via NYC if not absolutely necessary.

jak>> Is this a realistic deployment scenerio? I don't know what the RTT
packet latency is between NYC and London, but from San Jose, we
typically get somewhere around 100-130 ms to Europe. I'm not sure that
this would be acceptable even for control traffic. I think that any
deployment which would experience delay/latency/jitter for application
traffic might also have problems for control traffic too.
[Emek] If you find it nonrealistic scenario then how about a local /
domestic insurance company or a bank with local HQ and many local small
offices? The point I am trying to make is that even if (respectfully)
you and I cannot agree it shouldn't restrain the protocol from providing
such an alternative.

AC as a single point of failure is another point. Sustain existing Wi-Fi
sessions while AC experience failure or experience network outage
between WTP and AC.

jak>> Yes, that seems to be a realistic reason. It is also a reason for
thinking about mechanisms for failover of the WTC to another AC in the
control protocol. In some cases, it might be acceptable to have tunnel
failover slightly delayed; in others, possibly not.

...

CAPWAP is about Control and Provisioning. It says nothing about the
user's data frames path.
One more point, it's not mandatory that AC will be a dedicated HW
appliance. It could be a piece of software runs on any platform.
Overwhelming the AC with user's data implicitly dictates the former.

jak>> I'm not so sure. There have been some arguments advanced why 
jak>> putting
the distribution function at the AC would be desirable. You list them
below.

It should be the other way around - one should come with a very good
reason to execute bridging at the AC. In my opinion the protocol shell
facilitate both, letting the operator the freedom to chose.
To name a few reasons to consider bridging at the AC:
1. Statistics: AC can extract raw statistics / info from 802.11 frames.
2. Apply policy at the AC rather then at the WTP - simpler WTP.
3. If AC is a Layer 3 roaming facilitator.
4. If AC implements 802.11 encryption / decryption.

jak>> So it seems you are proposing to separate the control and data 
jak>> plane,
and then some way in the control protocol to negotiate how the data
plane is handled? Is that correct?
[Emek] It's exactly what I am proposing.

            jak