From diameter-admin@frascone.com Tue Mar 1 05:14:44 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09236 for ; Tue, 1 Mar 2005 05:14:43 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3C96B205E1 for ; Tue, 1 Mar 2005 05:14:44 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 611E6205CB for ; Tue, 1 Mar 2005 05:14:39 -0500 (EST) Date: Tue, 01 Mar 2005 05:14:39 -0500 Message-ID: <20050301101439.348.34842.Mailman@xavier> Subject: frascone.com mailing list memberships reminder From: mailman-owner@wolverine.cnri.reston.va.us To: capwap-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: diameter-admin@frascone.com Errors-To: diameter-admin@frascone.com X-BeenThere: diameter@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a reminder, sent out once a month, about your frascone.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, capwap-request@frascone.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@wolverine. Thanks! Passwords for capwap-archive@lists.ietf.org: List Password // URL ---- -------- capwap@frascone.com xakour http://mail.frascone.com/mailman/options/capwap/capwap-archive%40lists.ietf.org From capwap-admin@frascone.com Tue Mar 1 15:55:12 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10065 for ; Tue, 1 Mar 2005 15:55:10 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B817F20536; Tue, 1 Mar 2005 15:55:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CB8012053B; Tue, 1 Mar 2005 15:55:02 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A75D20536 for ; Tue, 1 Mar 2005 15:54:02 -0500 (EST) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 3675720531 for ; Tue, 1 Mar 2005 15:53:59 -0500 (EST) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j21KhpXM021676 for ; Tue, 1 Mar 2005 15:43:51 -0500 (EST) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j21KhSXM020978 for ; Tue, 1 Mar 2005 15:43:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details Message-ID: <5844A41F4E146044A2E8356C6328588007EDC0D5@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details Thread-Index: AcUdQlKqljmn/EU0T6O1Cx9pAYbS4wBW0rbg From: "Sadot, Emek (Emek)" To: "Cheng Hong" , "James Kempf" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 1 Mar 2005 15:51:09 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Cheng, Don't get me wrong, I think such an objective should be present while at the same time we should be limit the possible permutations. The APF AHC will/should not split the functionality between WTP and AC rather name and define atomic components/functionality that could reside at the WTP (or AC). Let take an (extreme) example, as part of the arch/protocol do we intend to allow the 802.1x authenticator component to reside at the WTP? Should an AC support such configuration? I would say no, but according to the objective document it's allowed. Jak, I share your concern, however I believe we should not call for one arch over the other, rather let the market/vendors solidified (or not) on one. In my mind, political hurdles - vendors already support different architectures - supported by technical merits for each arch will make it impossible to set up such an objective. Emek -----Original Message----- From: Cheng Hong [mailto:hcheng@psl.com.sg]=20 Sent: Sunday, February 27, 2005 10:05 PM To: Sadot, Emek (Emek); 'James Kempf'; capwap@frascone.com Subject: RE: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details Hi Emek, I think the issue is not on whether we should have the objective, rather, it is on how far we want to go. You are right that to support every possible split implementation permutation is almost impossible. However, the situation here should be better than that :)=20 Looking at the CAPWAP case, the maximum set of functions to be provided by AC is clearly defined by the IEEE802.11. (anything beyond that probably is out of scope of CAPWAP) Hopefully, the APF AHC will have a clean definition of possible splits. Anyway, there are only 9 types of services defined in 11. The complexity is still manageable. =20 Also, (assumable) everyone has participated in the taxonomy survey and review. We don't see hundreds of permutation defined there :) I guess that draft contains almost all the permutations we may see on the market. If that is still too much, we can modify the charter to clearly state which types of architecture should be in scope of CAPWAP (and forget about all the other permutations).=20 Back to the objective, to support different permutation is basically to design the CAPWAP protocol so that protocol components/messages supporting these different splits are as modular and independent as possible. The negotiation will allow AC to decide which protocol components should be involved. This definitely requires some in-depth understanding of the 11 MAC. Maybe that is a good reason to keep the APF AHC alive in IEEE802.11, and have the CAPWAP protocol reviewed there. cheers Cheng Hong > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Sadot, Emek (Emek) > Sent: Saturday, February 26, 2005 11:34 AM > To: James Kempf; capwap@frascone.com > Subject: RE: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective=20 > Details >=20 >=20 > The other side of the coin is the question how many permutations would > the protocol allows within each group - Split and Local. E.g. does the > protocol allows the existent of several distinct Split WTPs each with=20 > different (APF) set of components? >=20 > My concern lies at the AC side and the complexity involved. >=20 > Emek >=20 > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Friday, February 25, 2005 12:46 PM > To: Sadot, Emek (Emek); capwap@frascone.com > Subject: Re: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective=20 > Details >=20 > Emek/All, >=20 > Thanx for bringing this up. This objective is something I have been=20 > wondering about. >=20 > From a service provider perspective, having support for both local and > split MAC does not seem to be such a good idea. It makes both the AC=20 > and WTP more complicated, complicating the configuration and=20 > management. I know that the vendors are basically not in agreement=20 > about the right technical solution, and that some vendors are=20 > providing split MAC while others are providing local, so I'm afraid=20 > any attempt at an objective discussion on this will degenerate into=20 > both sides supporting their particular product offering with material=20 > from their respective marketing departments. The other problem with=20 > trying to choose is that I can think of good technical reasons in=20 > support of both alternatives. I can also think of good nontechnical=20 > reasons to choose one or the other. >=20 > One way we could solve this problem is to structure the protocol such=20 > that the two choices are clearly separate and let the market decide=20 > which way to go.That way, if CAPWAP is progressed to Draft Standard,=20 > if one or the other fails to achieve widespread deployment, the=20 > alternative that is not deployed can be EOLed. >=20 > There are other possible ways to cleanly separate the two, but they=20 > involve making some kind of value judgement that, I'm sure, one side=20 > or the other will object to based on the perceived impact of that=20 > judgement on their market capture potential. >=20 > jak >=20 >=20 > ----- Original Message ----- > From: "Sadot, Emek (Emek)" > To: > Sent: Thursday, February 24, 2005 7:42 PM > Subject: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details >=20 >=20 > "5.1.1 Objective Details >=20 >=20 > This objective for the CAPWAP protocol is to ensure that WTPs of=20 > both > local MAC and split MAC architecture designs are capable of > interoperation within a single WLAN. Consequently, a single WLAN > controller will be capable of controlling both types of WTPs using=20 > a > single CAPWAP protocol. Integral support for these designs=20 > comprises > a number of protocol aspects. > i. Functionality negotiations between WLAN controller and WTPs Local=20 > MAC and split MAC designs differ in the degree of IEEE 802.11 MAC=20 > functionalities that each type of WTP realizes. The CAPWAP protocol=20 > should allow WLAN controllers to determine the functionalities of=20 > different WTPs as a first step in controlling them." "determine the=20 > functionalities of different WTPs" - we should not assume that all=20 > Local and Split WTP vendors will select the same set of atomic=20 > components, t.b.d. by the APF WG - result in one instance of Local and > one per Split WTP. On the other hand we should be careful allowing any > permutation of the atomic APF components which could lead into=20 > hundreds (ok, ok, so I am exaggerating a bit) of instances per each=20 > group (Local and Split). >=20 >=20 > Regards, >=20 > Emek Sadot >=20 > System Architect Group >=20 > Avaya Communication >=20 > 732-852-2367 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap >=20 >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Mar 1 18:09:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21171 for ; Tue, 1 Mar 2005 18:09:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3A9A820587; Tue, 1 Mar 2005 18:09:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EB3992045C; Tue, 1 Mar 2005 18:09:02 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7D3652045C for ; Tue, 1 Mar 2005 18:08:56 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 44BC52036B for ; Tue, 1 Mar 2005 18:08:54 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21N8qZ24021; Wed, 2 Mar 2005 01:08:52 +0200 (EET) X-Scanned: Wed, 2 Mar 2005 01:08:21 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j21N8LuA032159; Wed, 2 Mar 2005 01:08:21 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00WnxGY6; Wed, 02 Mar 2005 01:08:20 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21N8HM15173; Wed, 2 Mar 2005 01:08:17 +0200 (EET) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Mar 2005 17:07:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Call for CAPWAP protocol proposals Thread-Index: AcUes3RAzxHc/wiaRMe1eriMbaSQaw== From: To: Cc: X-OriginalArrivalTime: 01 Mar 2005 23:07:36.0073 (UTC) FILETIME=[74FE4F90:01C51EB3] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Call for CAPWAP protocol proposals Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 1 Mar 2005 15:07:34 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable According to our milestones, the deadline to submit protocol proposals to the WG is the end of March. If you wish to champion a new or = existing protocol to the CAPWAP WG, please post a draft to the WG list for consideration. If multiple protocol submissions are received, the CAPWAP Evaluation Work Item will select the protocol that best meets the Problem statement and the Objectives draft(work in progress).=20 Thanks, Mani and Dorothy=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Mar 1 21:50:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08805 for ; Tue, 1 Mar 2005 21:50:04 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5323420594; Tue, 1 Mar 2005 21:50:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DD59620569; Tue, 1 Mar 2005 21:50:02 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7DC0A2052E for ; Tue, 1 Mar 2005 21:50:00 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 02897204CF for ; Tue, 1 Mar 2005 21:49:56 -0500 (EST) Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j222kBuT014939; Wed, 2 Mar 2005 10:46:16 +0800 (SGT) From: "Cheng Hong" To: "'Sadot, Emek (Emek)'" , "'James Kempf'" , Subject: RE: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details Organization: Panasonic Singapore Laboratories Message-ID: <005a01c51ed2$75ba0d60$4971510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <5844A41F4E146044A2E8356C6328588007EDC0D5@nj7460avexu2.global.avaya.com> Importance: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 2 Mar 2005 10:49:24 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Emek, > Don't get me wrong, I think such an objective should be=20 > present while at the same time we should be limit the=20 > possible permutations. The APF AHC will/should not split the=20 > functionality between WTP and AC rather name and define=20 > atomic components/functionality that could reside at the WTP (or AC). >=20 > Let take an (extreme) example, as part of the arch/protocol=20 > do we intend to allow the 802.1x authenticator component to=20 > reside at the WTP? Should an AC support such configuration? I=20 > would say no, but according to the objective document it's allowed. Yes. I agree that the possible permutations to be supported by the = CAPWAP should be limited. =20 As for the example above, I guess that is a valid question to the whole group. Do we want to preclude certain implementation possibilities explicitly? Maybe we should make use of the taxonomy draft as the = guideline? As mentioned by Jak, before market settle down, we probably need to = support both.=20 cheers Cheng Hong > Jak, > I share your concern, however I believe we should not call=20 > for one arch over the other, rather let the market/vendors=20 > solidified (or not) on one. In my mind, political hurdles -=20 > vendors already support different architectures - supported=20 > by technical merits for each arch will make it impossible to=20 > set up such an objective. >=20 > Emek >=20 > -----Original Message----- > From: Cheng Hong [mailto:hcheng@psl.com.sg]=20 > Sent: Sunday, February 27, 2005 10:05 PM > To: Sadot, Emek (Emek); 'James Kempf'; capwap@frascone.com > Subject: RE: [Capwap] CAPWAP Objectives rev00 - 5.1.1=20 > Objective Details >=20 > Hi Emek, >=20 > I think the issue is not on whether we should have the=20 > objective, rather, it is on how far we want to go. You are=20 > right that to support every possible split implementation=20 > permutation is almost impossible. However, the situation here=20 > should be better than that :)=20 >=20 > Looking at the CAPWAP case, the maximum set of functions to=20 > be provided by AC is clearly defined by the IEEE802.11.=20 > (anything beyond that probably is out of scope of CAPWAP)=20 > Hopefully, the APF AHC will have a clean definition of=20 > possible splits. Anyway, there are only 9 types of services=20 > defined in 11. The complexity is still manageable. =20 >=20 > Also, (assumable) everyone has participated in the taxonomy=20 > survey and review. We don't see hundreds of permutation=20 > defined there :) I guess that draft contains almost all the=20 > permutations we may see on the market. If that is still too=20 > much, we can modify the charter to clearly state which types=20 > of architecture should be in scope of CAPWAP (and forget=20 > about all the other permutations).=20 >=20 > Back to the objective, to support different permutation is=20 > basically to design the CAPWAP protocol so that protocol=20 > components/messages supporting these different splits are as=20 > modular and independent as possible. The negotiation will=20 > allow AC to decide which protocol components should be=20 > involved. This definitely requires some in-depth=20 > understanding of the 11 MAC. Maybe that is a good reason to=20 > keep the APF AHC alive in IEEE802.11, and have the CAPWAP=20 > protocol reviewed there. >=20 > cheers >=20 > Cheng Hong >=20 >=20 > > -----Original Message----- > > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On=20 > > Behalf Of Sadot, Emek (Emek) > > Sent: Saturday, February 26, 2005 11:34 AM > > To: James Kempf; capwap@frascone.com > > Subject: RE: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective > > Details > >=20 > >=20 > > The other side of the coin is the question how many=20 > permutations would >=20 > > the protocol allows within each group - Split and Local.=20 > E.g. does the >=20 > > protocol allows the existent of several distinct Split WTPs=20 > each with > > different (APF) set of components? > >=20 > > My concern lies at the AC side and the complexity involved. > >=20 > > Emek > >=20 > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Friday, February 25, 2005 12:46 PM > > To: Sadot, Emek (Emek); capwap@frascone.com > > Subject: Re: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective > > Details > >=20 > > Emek/All, > >=20 > > Thanx for bringing this up. This objective is something I have been > > wondering about. > >=20 > > From a service provider perspective, having support for=20 > both local and >=20 > > split MAC does not seem to be such a good idea. It makes both the AC > > and WTP more complicated, complicating the configuration and=20 > > management. I know that the vendors are basically not in agreement=20 > > about the right technical solution, and that some vendors are=20 > > providing split MAC while others are providing local, so I'm afraid=20 > > any attempt at an objective discussion on this will degenerate into=20 > > both sides supporting their particular product offering=20 > with material=20 > > from their respective marketing departments. The other problem with=20 > > trying to choose is that I can think of good technical reasons in=20 > > support of both alternatives. I can also think of good nontechnical=20 > > reasons to choose one or the other. > >=20 > > One way we could solve this problem is to structure the=20 > protocol such > > that the two choices are clearly separate and let the market decide=20 > > which way to go.That way, if CAPWAP is progressed to Draft=20 > Standard,=20 > > if one or the other fails to achieve widespread deployment, the=20 > > alternative that is not deployed can be EOLed. > >=20 > > There are other possible ways to cleanly separate the two, but they > > involve making some kind of value judgement that, I'm sure,=20 > one side=20 > > or the other will object to based on the perceived impact of that=20 > > judgement on their market capture potential. > >=20 > > jak > >=20 > >=20 > > ----- Original Message ----- > > From: "Sadot, Emek (Emek)" > > To: > > Sent: Thursday, February 24, 2005 7:42 PM > > Subject: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details > >=20 > >=20 > > "5.1.1 Objective Details > >=20 > >=20 > > This objective for the CAPWAP protocol is to ensure that WTPs of > > both > > local MAC and split MAC architecture designs are capable of > > interoperation within a single WLAN. Consequently, a single WLAN > > controller will be capable of controlling both types of=20 > WTPs using=20 > > a > > single CAPWAP protocol. Integral support for these designs=20 > > comprises > > a number of protocol aspects. > > i. Functionality negotiations between WLAN controller and=20 > WTPs Local=20 > > MAC and split MAC designs differ in the degree of IEEE 802.11 MAC=20 > > functionalities that each type of WTP realizes. The CAPWAP protocol=20 > > should allow WLAN controllers to determine the functionalities of=20 > > different WTPs as a first step in controlling them." "determine the=20 > > functionalities of different WTPs" - we should not assume that all=20 > > Local and Split WTP vendors will select the same set of atomic=20 > > components, t.b.d. by the APF WG - result in one instance=20 > of Local and >=20 > > one per Split WTP. On the other hand we should be careful=20 > allowing any >=20 > > permutation of the atomic APF components which could lead into > > hundreds (ok, ok, so I am exaggerating a bit) of instances per each=20 > > group (Local and Split). > >=20 > >=20 > > Regards, > >=20 > > Emek Sadot > >=20 > > System Architect Group > >=20 > > Avaya Communication > >=20 > > 732-852-2367 > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > >=20 > >=20 > >=20 >=20 >=20 >=20 >=20 >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 2 12:38:05 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07643 for ; Wed, 2 Mar 2005 12:38:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 632482048C; Wed, 2 Mar 2005 12:38:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7C7FC2045A; Wed, 2 Mar 2005 12:38:02 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C77342045A for ; Wed, 2 Mar 2005 12:37:40 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id A2E0220455 for ; Wed, 2 Mar 2005 12:37:37 -0500 (EST) Message-ID: <04bf01c51f4e$acf0f5b0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Cheng Hong" , "'Sadot, Emek (Emek)'" , References: <005a01c51ed2$75ba0d60$4971510a@Palpatine> Subject: Re: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 2 Mar 2005 09:38:34 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit >As for the example above, I guess that is a valid question to the whole >group. Do we want to preclude certain implementation possibilities >explicitly? Maybe we should make use of the taxonomy draft as the guideline? >As mentioned by Jak, before market settle down, we probably need to support >both. As mentioned, I don't think it is possible to remove certain implementation possibilities due to market realities. But I think the standard needs to limit the possible deployment permutations to reduce the complexity of network management. In particular, I think there are likely to be some deployment configurations that provide marginal or no advantages over others. Of course, if a particular deployment configuration provides clearly definable advantages, then it should be included. Therefore, it might help when deciding whether to support a particular combination of local and split MAC to weigh the deployment advantages and complexities of the combination and make a decision based on that. jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 2 21:20:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27377 for ; Wed, 2 Mar 2005 21:20:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 540AA202A2; Wed, 2 Mar 2005 21:20:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 329DF202DC; Wed, 2 Mar 2005 21:20:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AE53C202CA for ; Wed, 2 Mar 2005 21:19:52 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 2F259202A2 for ; Wed, 2 Mar 2005 21:19:49 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j232GG3O003806; Thu, 3 Mar 2005 10:16:16 +0800 (SGT) Message-Id: <200503030216.j232GG3O003806@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: "'James Kempf'" , "'subrata goswami'" Cc: Subject: RE: [Capwap] Additional Requirement? Organization: Panasonic Singapore Laboratories MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUaneJfK62+jeLZSOCM07QS2AjnCAE+RM2A In-Reply-To: <08a401c51a9e$4a479f90$016115ac@dcml.docomolabsusa.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 3 Mar 2005 10:19:29 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi James, Apologies for the late reply. It is a good point you raise that CAPWAP needs to be able to run independent of IP versions. The Interconnection objective (5.2.6) tries to capture this requirement. It suggests that the CAPWAP protocol be independent of underlying transport technology. Maybe we can add IPv4 and IPv6 specifically as transport technologies that the protocol must be independent of. Consider revising the paragraph 2 of the Description (5.2.6), last sentence: Current text: "As a result of realizing this objective, the protocol will be capable of operation over different interconnect technologies including Ethernet, bus backplanes, ATM (cell) fabrics and also wireless technologies such as IEEE 802.11." Proposed text: "As a result of realizing this objective, the protocol will be capable of operation over different interconnect technologies including Ethernet, IPv4, IPv6, bus backplanes, ATM (cell) fabrics and also wireless technologies such as IEEE 802.11." Does this capture your suggestion for IP version independence? Cheers, Saravanan > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > Sent: Friday, February 25, 2005 2:26 AM > To: subrata goswami; Saravanan Govindan > Cc: capwap@frascone.com > Subject: [Capwap] Additional Requirement? > > I don't recall seeing anything about independence of IP > version. I think CAPWAP needs to be defined such that it will > run on IPv4 or IPv6. > > jak > > ----- Original Message ----- > From: "subrata goswami" > To: "Saravanan Govindan" > Cc: ; > Sent: Thursday, February 24, 2005 8:33 AM > Subject: Re: [Capwap] Additions #12 - Future Wireless Technologies > > > > Saravanan , seems okay to me. > > > > Subrata > > > > > > Saravanan Govindan wrote: > > > > >Hi Subrata, James, > > > > > >Thank you for your comments and suggestions. > > > > > >In summary, the suggestion is to clearly specify what the > CAPWAP protocol > needs in terms of > > >applicability to 802.11 and non-802.11 technologies. > > > > > >Please consider the following text which combines the > proposals from > James and Subrata. > > > > > >------- > > >(Include the following in Description) > > > > > >"In all cases where the CAPWAP protocol messages contain > specific Layer 2 > information elements, the > > >definition of the protocol needs to provide for > extensibility so that > these elements can be defined > > >for specific layer 2 wireless protocols. This may entail > assigning a > layer 2 wireless protocol type > > >and version field to the message PDU. Examples of other wireless > protocols that might be supported > > >include but are not limited to 802.16e, 802.15.x, etc." > > >----XXXX---- > > > > > >Cheers, > > > > > >Saravanan > > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > > >>From: capwap-admin@frascone.com > > >>[mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > > >>Sent: Thursday, February 24, 2005 1:57 AM > > >>To: subrata goswami; capwap@frascone.com > > >>Subject: Re: [Capwap] Additions #12 - Future Wireless Technologies > > >> > > >> > > >> > > >> > > >>>>"In all cases where the CAPWAP protocol messages > contain specific > > >>>>Layer 2 information elements, the definition of the > > >>>> > > >>>> > > >>protocol needs to > > >> > > >> > > >>>>provide for extensibility so that these elements can be > > >>>> > > >>>> > > >>defined for > > >> > > >> > > >>>>wireless > > >>>> > > >>>> > > >>protocols > > >> > > >> > > >>>>other than 802.11." > > >>>> > > >>>> > > >>>> > > >>>> > > >>>"In all cases where the CAPWAP protocol messages contain specific > > >>>Layer 2 information elements, the definition of the > > >>> > > >>> > > >>protocol needs to > > >> > > >> > > >>>provide for extensibility so that these elements can be > defined for > > >>>specific layer 2 wireless protocols (e.g. 802.11, > 802.16, 802.15.x > > >>>etc). This may > > >>> > > >>> > > >>The problem with mentioning these is it might be construed to > > >>exclude others. If you want to include specific reference, > > >>I'd suggest adding a sentence at the end of the paragraph > > >>that says something like: > > >> > > >>"Examples of other wireless protocols that might be supported > > >>include but are not limited to 802.16e, 802.15.x, etc. > > >> > > >> > > >> > > >>>entail assigning a layer 2 wireless protocol type and > > >>> > > >>> > > >>version field to > > >> > > >> > > >>>the message PDU. " > > >>> > > >>> > > >>> > > >>Hmm, well, that's a bit too specific for a requirement. But, > > >>off the top of my head, I can't think of any other way one > > >>could do this, so I suppose it's OK. > > >> > > >> jak > > >> > > >> > > >> > > >>_______________________________________________ > > >>Capwap mailing list > > >>Capwap@frascone.com > > >>http://mail.frascone.com/mailman/listinfo/capwap > > >> > > >> > > >> > > > > > >_______________________________________________ > > >Capwap mailing list > > >Capwap@frascone.com > > >http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Mar 3 02:19:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09487 for ; Thu, 3 Mar 2005 02:19:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4CF3020477; Thu, 3 Mar 2005 02:19:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0896E20443; Thu, 3 Mar 2005 02:19:02 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7312C20443 for ; Thu, 3 Mar 2005 02:18:13 -0500 (EST) Received: from cmccmta (webmail.chinamobile.com [211.136.27.4]) by mail.frascone.com (Postfix) with ESMTP id 6065F20433 for ; Thu, 3 Mar 2005 02:18:09 -0500 (EST) Received: from zhouwenhui ([10.1.5.8]) by mail.chinamobile.com (Lotus Domino Release 5.0.12) with SMTP id 2005030315181025:54 ; Thu, 3 Mar 2005 15:18:10 +0800 Message-ID: <00ee01c51fc1$1e7d3b40$0100a8c0@zhouwenhui> From: "Wenhui Zhou" To: References: <20050216170004.26258.30783.Mailman@xavier> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 5.0.12 |February 13, 2003) at 2005-03-03 03:18:10 PM, Serialize by Router on cmccmta/servers/cmcc(Release 5.0.6a |January 17, 2001) at 2005-03-03 03:14:36 PM, Serialize complete at 2005-03-03 03:14:36 PM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Re: Capwap digest, Vol 1 #333 - 1 msg Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 3 Mar 2005 15:13:05 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: base64 SGksIERvcm90aHkNCg0KbWF5IGkgaGF2ZSBzb21lIGRpc2N1c3Npb24gd2l0aCB5b3Ugb24gdGhl IEN1c3RvbSBSZXF1aXJlbWVudHMgc2VjdGlvbiBpbiBlYWNoIHJlcXVpcmVtZW50Pw0KDQo+IDEu IChnZW5lcmFsKSAgQ3VzdG9tZXIgUmVxdWlyZW1lbnRzIHNlY3Rpb24gc2hvdWxkIG5vdCBiZSBh IHN1Yi1zZWN0aW9uID0NCj4gb2YgZWFjaCBPYmplY3RpdmUsIGJ1dCByYXRoZXIgYSBzZXBhcmF0 ZSBzZWN0aW9uIGZvciBTZXJ2aWNlIFByb3ZpZGVycyA9DQo+IHRvIGxpc3QgdGhlaXIgcmVxdWly ZW1lbnRzLiAgQXMgdGhlIGRyYWZ0J3MgYXV0aG9yIGxpc3QgaW5jbHVkZXMgPQ0KPiBPcGVyYXRv cnMsIHRoaXMgc2VjdGlvbiBzaG91bGQgbGlzdCBPcGVyYXRvciBTcGVjaWZpYyByZXF1aXJlbWVu dHMgdGhhdCA9DQo+IG1heSBiZSBtaXNzZWQgYnkgZXF1aXBtZW50IHZlbmRvcnMuID0yMA0KPiAN Cg0KTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgQ3VzdG9tZXIgUmVxdWlyZW1lbnRzIHNlY3Rpb24g aW4gZWFjaCByZXF1aXJlbWVudCBpcyB0byBnaXZlIHdoYXQgd2lsbCBiZSBtZXQgYnkgaW1wbGVt ZW50aW5nIGl0IG9yIHRoZSB0aGUgYmVuZWZpdCBvZiB0aGUgcmVxdWlyZW1lbnQgdG8gdGhlIGN1 c3RvbWVycy4gSW4gZmFjdCwgYWxsIG9mIHRoZSBhcmNoaXRlY3R1cmUsIG9wZXJhdGlvbmFsIGFu ZCBzZWN1cml0eSByZXF1aXJlbWVudHMgY2FuIGJlIHVuZGVyc3Rvb2QgYXMgY3VzdG9tZXIgcmVx dWlyZW1lbnRzLg0KDQpzbyBpIGd1ZXNzIGlmIHlvdSBuZWVkIHRoZSBzZXBlcmF0ZSBzZWN0aW9u IG9mIEN1c3RvbWVyIFJlcXVpcmVtZW50IHRoYXQgZ2l2ZXMgaGlnaGVyIGxldmVsIHJlcXVpcmVt ZW50IHRoYW4gdGhvc2UgZ2l2ZW4gb25lIGJ5IG9uZSBpbiB0aGUgZHJhZnQ/DQoNCmNvdWxkIHlv dSBwbHMuIGdpdmUgdXMgc29tZSBjbGFyaWZpY2F0aW9uIG9uIGl0PyB0aGFua3MuDQoNCkJyLnpo b3Ugd2VuaHVpDQpTZW5pb3IgUHJvamVjdCBNYW5hZ2VyLA0KUiZEIENlbnRlciwNCkNoaW5hIE1v YmlsZQ0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiA8Y2Fwd2FwLXJl cXVlc3RAZnJhc2NvbmUuY29tPg0KVG86IDxjYXB3YXBAZnJhc2NvbmUuY29tPg0KU2VudDogVGh1 cnNkYXksIEZlYnJ1YXJ5IDE3LCAyMDA1IDE6MDAgQU0NClN1YmplY3Q6IENhcHdhcCBkaWdlc3Qs IFZvbCAxICMzMzMgLSAxIG1zZw0KDQoNCj4gU2VuZCBDYXB3YXAgbWFpbGluZyBsaXN0IHN1Ym1p c3Npb25zIHRvDQo+IGNhcHdhcEBmcmFzY29uZS5jb20NCj4gDQo+IFRvIHN1YnNjcmliZSBvciB1 bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2aXNpdA0KPiBodHRwOi8vbWFpbC5m cmFzY29uZS5jb20vbWFpbG1hbi9saXN0aW5mby9jYXB3YXANCj4gb3IsIHZpYSBlbWFpbCwgc2Vu ZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvDQo+IGNhcHdhcC1yZXF1 ZXN0QGZyYXNjb25lLmNvbQ0KPiANCj4gWW91IGNhbiByZWFjaCB0aGUgcGVyc29uIG1hbmFnaW5n IHRoZSBsaXN0IGF0DQo+IGNhcHdhcC1hZG1pbkBmcmFzY29uZS5jb20NCj4gDQo+IFdoZW4gcmVw bHlpbmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lm aWMNCj4gdGhhbiAiUmU6IENvbnRlbnRzIG9mIENhcHdhcCBkaWdlc3QuLi4iDQo+IA0KPiANCj4g VG9kYXkncyBUb3BpY3M6DQo+IA0KPiAgICAxLiBDb21tZW50cyBvbiBDQVBXQVAgT2JqZWN0aXZl cyBkcmFmdCAoRG9yb3RoeS5HZWxsZXJ0QG5va2lhLmNvbSkNCj4gDQo+IC0tX18tLV9fLS0NCj4g DQo+IE1lc3NhZ2U6IDENCj4gRGF0ZTogVHVlLCAxNSBGZWIgMjAwNSAxNTo1NjoxMiAtMDgwMA0K PiBGcm9tOiA8RG9yb3RoeS5HZWxsZXJ0QG5va2lhLmNvbT4NCj4gVG86IDxjYXB3YXBAZnJhc2Nv bmUuY29tPg0KPiBDYzogPG1tYW5pQGF2YXlhLmNvbT4sIDxEb3JvdGh5LkdlbGxlcnRAbm9raWEu Y29tPg0KPiBTdWJqZWN0OiBbQ2Fwd2FwXSBDb21tZW50cyBvbiBDQVBXQVAgT2JqZWN0aXZlcyBk cmFmdA0KPiANCj4gDQo+IEhlcmUgYXJlIHNvbWUgY29tbWVudHMgdGhlIGNoYWlycyBoYXZlIG9u IHRoZSBPYmplY3RpdmVzIGRyYWZ0LiAgV2UgYWxzbyA9DQo+IHByb3ZpZGVkIHByaW9yaXR5IGNs YXNzaWZpY2F0aW9ucyBmb3IgZWFjaCBvYmplY3RpdmUgYXMgZGVzY3JpYmVkIGluIHRoZSA9DQo+ IGNoYXJ0ZXIuICBJIGhvcGUgdGhpcyBnZW5lcmF0ZXMgc29tZSBkaXNjdXNzaW9uIGFuZCBtb3Jl IGNvbW1lbnRzLiA9MjANCj4gDQo+IEtlZXAgaW4gbWluZCB0aGF0IHdlIGFyZSBsb29raW5nIGZv ciBhIG1pbmltYWwgc2V0IG9mIHJlcXVpcmVtZW50cyA9DQo+IG5lZWRlZCBmb3IgYW4gaW50ZXJv cGVyYWJsZSBwcm90b2NvbC4gID0yMA0KPiANCj4gUmVnYXJkcywNCj4gRG9yb3RoeQ0KPiANCj4g DQo+IDEuIChnZW5lcmFsKSAgQ3VzdG9tZXIgUmVxdWlyZW1lbnRzIHNlY3Rpb24gc2hvdWxkIG5v dCBiZSBhIHN1Yi1zZWN0aW9uID0NCj4gb2YgZWFjaCBPYmplY3RpdmUsIGJ1dCByYXRoZXIgYSBz ZXBhcmF0ZSBzZWN0aW9uIGZvciBTZXJ2aWNlIFByb3ZpZGVycyA9DQo+IHRvIGxpc3QgdGhlaXIg cmVxdWlyZW1lbnRzLiAgQXMgdGhlIGRyYWZ0J3MgYXV0aG9yIGxpc3QgaW5jbHVkZXMgPQ0KPiBP cGVyYXRvcnMsIHRoaXMgc2VjdGlvbiBzaG91bGQgbGlzdCBPcGVyYXRvciBTcGVjaWZpYyByZXF1 aXJlbWVudHMgdGhhdCA9DQo+IG1heSBiZSBtaXNzZWQgYnkgZXF1aXBtZW50IHZlbmRvcnMuID0y MA0KPiANCj4gMi4gKGdlbmVyYWwpICBTb21lIG9mIHRoZSBPYmplY3RpdmUgU2VjdGlvbiBpbmNs dWRlIHN1YnNlY3Rpb24uICBUaGVzZSA9DQo+IHNob3VsZCBiZSBwdWxsZWQgb3V0IHNvIHdlIGNh biBwcmlvcml0aXplIHRoZW0gb24gdGhlaXIgb3duIG1lcml0Lg0KPiAgRXhhbXBsZTogIDUuMi4z LmksIGlpLCBpaWksIDUuMi40LmksIGlpLCBpaWksIDUuMi41LmksIGlpDQo+IA0KPiAzLiAoZ2Vu ZXJhbCkgIFdlIG5lZWQgdG8gY2xlYXJseSBzdGF0ZSB0aGUgUmVxdWlyZW1lbnQgaW4gZWFjaCA9 DQo+IG9iamVjdGl2ZS4gIEkgZG9uJ3QgYmVsaWV2ZSB0aGUgdGl0bGUgb2YgdGhlIG9iamVjdGl2 ZSBpcyBlbm91Z2guICBUaGUgPQ0KPiB3YXkgaXRzIHN0YXRlZCBub3cgd2UgaGF2ZSB0byBzdXJt aXNlIHRoZSByZXF1aXJlbWVudCBmcm9tIHRoZSA9DQo+IGRlc2NyaXB0aW9uLiA9MjANCj4gDQo+ IDQuIChnZW5lcmFsKSAgU2VjdGlvbiA1LjMgbmVlZHMgdG8gYmUgbW92ZWQgaW50byB0aGUgaW50 cm8gc2VjdGlvbi4NCj4gDQo+IE9iamVjdGl2ZTogNS4yLjMuaTogIExvZ2ljYWwgR3JvdXBzLCBQ cmlvcml0eTogIE1hbmRhdG9yeQ0KPiBPYmplY3RpdmUgNS4yLjMuaWk6ICBTaG91bGQgdGhpcyBi ZSBNdXR1YWwgRXhjbHVzaW9uIG9mIENvbnRyb2wgYW5kID0NCj4gRGF0YT8gIFByaW9yaXR5OiAg TWFuZGF0b3J5DQo+IE9iamVjdGl2ZSA1LjIuMy5paWk6ICBNdWx0aXBsZSBBdXRoZW50aWNhdGlv biBNZWNoYW5pc21zOiAgRGVzaXJhYmxlLiA9MjANCj4gLSA4MDIuMTFpIHNob3VsZCBiZSByZXF1 aXJlbWVudCwgbm90IGFuIG9wdGlvbi4gPTIwDQo+IA0KPiBPYmplY3RpdmUgNS4yLjQuaTogIEVu YWJsZSBzdXBwb3J0IGZvciBmdXR1cmUgd2lyZWxlc3MgdGVjaG5vbG9naWVzOiAgPQ0KPiBEZXNp cmFibGUNCj4gLSA4MDIuMTEgZmlyc3QsIDgwMi4xNiByZXF1aXJlbWVudHMgaW4gcGhhc2UgMSB0 aW1lIHBlcm1pdHRpbmcuICBBcyA9DQo+IHN0YXRlZCBpbiBDaGFydGVyLg0KPiBPYmplY3RpdmUg NS4yLjQuaWk6ICBFbmFibGUgc3VwcG9ydCBmb3IgbmV3IElFRUUgcmVxdWlyZW1lbnRzOiBEZXNp cmFibGUNCj4gT2JqZWN0aXZlIDUuMi40LmlpaSAgQWNjZXNzIFJlcXVpcmVtZW50czogIERvIHlv dSBtZWFuIHRyYW5zcGFyZW5jeSA9DQo+IGhlcmU/ICBUaGlzIGlzIHVuY2xlYXIuICBUcmFuc3Bh cmVuY3kgc2hvdWxkIGJlIE1hbmRhdG9yeQ0KPiANCj4gT2JqZWN0aXZlIDUuMi41Lmk6ICBDb25m aWd1cmF0aW9uIENvbnNpc3RlbmN5OiAgUHJpb3JpdHk6ICBNYW5kYXRvcnk9MjANCj4gLSBJcyB0 aGUgcmVxdWlyZW1lbnQgdG8gdXBkYXRlIGNvbmZpZ3VyYXRpb24gaW5mbyB0byBBQz8gIERvIHlv dSBtZWFuID0NCj4gdG8gZ2V0IGludG8gUHJvdmlzaW9uaW5nIGhlcmU/ID0yMA0KPiAtIGZpcm13 YXJlIGRpc3RyaWJ1dGlvbiBuZWVkcyB0byBiZSBpdHMgb3duIHJlcXVpcmVtZW50LiAgU2hvdWxk IHRoaXMgPQ0KPiBiZSBvbiBjb250cm9sIG9yIGRhdGEgcGxhbmU/PTIwDQo+IE9iamVjdGl2ZSA1 LjIuNS5paTogIFN5c3RlbSBXaWRlIHJlc291cmNlIHN0YXRlOiAgUHJpb3JpdHkgTWFuZGF0b3J5 DQo+IC0gRGVmaW5lIHdoYXQgc3RhdGlzdGljcyBhcmUgbmVlZGVkLg0KPiA9MDkNCj4gT2JqZWN0 aXZlIDUuMi42OiAgUmVzb3VyY2UgQ29udHJvbCBPYmplY3RpdmVzOiAgUHJpb3JpdHk6ICBNYW5k YXRvcnkNCj4gLSBSZXF1aXJlbWVudCBpcyB0byBtYWludGFpbiB0aGUgODAyLjExZSBtYXBwaW5n LiAgQ2FuIHRoaXMgYmUgPQ0KPiBleHBhbmRlZCB0byBpbmNsdWRlIG90aGVyIDgwMi4xMSBURyBz ZW1hbnRpY3M/DQo+IA0KPiBPYmplY3RpdmUgNS4yLjcgVHJhZmZpYyBTZXBhcmF0aW9uOiA9MjAN Cj4gSXNuJ3QgdGhpcyBhIGR1cGxpY2F0ZSBvZiA1LjIuMy5paT8NCj4gDQo+IE9iamVjdGl2ZSA1 LjIuODogIFNUQSBBZG1pc3Npb24gQ29udHJvbCBPYmplY3RpdmVzICA9MDkNCj4gLSBOZWVkIHRv IGJlIGJldHRlciBkZWZpbmVkLiAgRG9uJ3Qga25vdyB3aGF0IHlvdSBhcmUgZ2V0dGluZyBhdCA9 DQo+IGhlcmUuDQo+IA0KPiBPYmplY3RpdmUgNS4yLjk6ICBDZW50cmFsaXplZCBXVFAgTWFuYWdl bWVudDoNCj4gLSBJc24ndCB0aGlzIGEgZHVwbGljYXRlIG9mIDUuMi41Lmk/DQo+IA0KPiBPYmpl Y3RpdmUgNS4yLjEwOiAgQ0FQV0FQIFByb3RvY29sIFNlY3VyaXR5OiAgUHJpb3JpdHk6ICBNYW5k YXRvcnkgPTIwDQo+IC0gSXMgdGhpcyBtdXR1YWwgYXV0aGVudGljYXRpb24sIHNob3VsZCBiZSBj bGFyaWZpZWQNCj4gDQo+IE9iamVjdGl2ZXMgNS4yLjExOiAgU3lzdGVtIFdpZGUgU2VjdXJpdHkg OiBQcmlvcml0eTogIE1hbmRhdG9yeQ0KPiANCj4gT2JqZWN0aXZlcyA1LjIuMTI6ICBDZW50cmFs aXplZCBXVFAgbWFuYWdlbWVudDogIFByaW9yaXR5OiAgUmVqZWN0ZWQNCj4gLSBJdCBzb3VuZHMg bGlrZSB5b3UgYXJlIHJlcXVlc3RpbmcgdGhlIEFDIG5vdCBwYXJ0aWNpcGF0ZSBpbiA9DQo+IG1h bmFnZW1lbnQuICBUaGlzIGRvZXNuJ3Qgc2VlbSByZWxldmFudCB0byBlc3RhYmxpc2hpbmcgYSBj b250cm9sIGFuZCA9DQo+IHByb3Zpc2lvbmluZyBwcm90b2NvbCBmb3IgQVBzLiBBdCB0aGUgdmVy eSBsZWFzdCBpdCBkb2Vzbid0IHNlZW0gbGlrZSBhID0NCj4gaGlnaCBwcmlvcml0eSByZXF1aXJl bWVudCBmb3IgYSBwaGFzZSAxIENBUFdBUCBwcm90b2NvbC4gPTIwDQo+IA0KPiBPYmplY3RpdmVz OiAgNS4yLjEzOiAgU2VjdXJpdHkgQm9yZGVybGluZSBDb250cm9sOiAgUHJpb3JpdHk6ICBEZXNp cmFibGUgPQ0KPiANCj4gLSBJcyB0aGlzIG5lY2Vzc2FyeSBmb3IgYSBwaGFzZSAxIENBUFdBUCBw cm90b2NvbD8NCj4gDQo+IE9iamVjdGl2ZSA1LjIuMTQ6ICBUcnVzdCBNb2RlbCBEZWZpbml0aW9u cw0KPiAtIElzIHRoaXMgYSBkdXBsaWNhdGUgb2YgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGluIDUu Mi4xMD8gPTIwDQo+IA0KPiBPYmplY3RpdmVzIDUuMi4xNTogICBJRUVFIDgwMi4xMWkgQ29uc2lk ZXJhdGlvbnMNCj4gLVdoYXQgaXMgdGhlIHByb3Bvc2FsIGZvciBrZXkgZGlzdHJpYnV0aW9uIGlu IGVhY2ggY2FzZT8gICBQcmlvcml0eSA9DQo+IE1hbmRhdG9yeSAoZm9yIGtleSBkaXN0cmlidXRp b24gb25seSkNCj4gLVdoYXQgb3RoZXIgY29uc2lkZXJhdGlvbnM/DQo+IA0KPiANCj4gDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IC0tX18tLV9fLS0NCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENhcHdhcCBtYWls aW5nIGxpc3QNCj4gQ2Fwd2FwQGZyYXNjb25lLmNvbQ0KPiBodHRwOi8vbWFpbC5mcmFzY29uZS5j b20vbWFpbG1hbi9saXN0aW5mby9jYXB3YXANCj4gDQo+IA0KPiBFbmQgb2YgQ2Fwd2FwIERpZ2Vz dA== _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Mar 3 02:37:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14346 for ; Thu, 3 Mar 2005 02:37:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA80B204A0; Thu, 3 Mar 2005 02:37:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 09C6220471; Thu, 3 Mar 2005 02:37:02 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9C2F620471 for ; Thu, 3 Mar 2005 02:36:36 -0500 (EST) Received: from cmccmta (webmail.chinamobile.com [211.136.27.4]) by mail.frascone.com (Postfix) with ESMTP id 4700620443 for ; Thu, 3 Mar 2005 02:36:32 -0500 (EST) Received: from zhouwenhui ([10.1.5.8]) by mail.chinamobile.com (Lotus Domino Release 5.0.12) with SMTP id 2005030315355294:230 ; Thu, 3 Mar 2005 15:35:52 +0800 Message-ID: <013901c51fc3$97b73fe0$0100a8c0@zhouwenhui> From: "Wenhui Zhou" To: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 5.0.12 |February 13, 2003) at 2005-03-03 03:35:53 PM, Serialize by Router on cmccmta/servers/cmcc(Release 5.0.6a |January 17, 2001) at 2005-03-03 03:32:58 PM, Serialize complete at 2005-03-03 03:32:58 PM Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Fw: Capwap digest, Vol 1 #333 - 1 msg Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 3 Mar 2005 15:35:37 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: base64 ZmFpbGVkIGF0IGZpcnN0IHRpbWUgYW5kIHNlbmQgaXQgYWdhaW4uDQotLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIA0KRnJvbTogIldlbmh1aSBaaG91IiA8emhvdXdlbmh1aUBjaGluYW1vYmls ZS5jb20+DQpUbzogPGNhcHdhcEBmcmFzY29uZS5jb20+DQpTZW50OiBUaHVyc2RheSwgTWFyY2gg MDMsIDIwMDUgMzoxMyBQTQ0KU3ViamVjdDogUmU6IENhcHdhcCBkaWdlc3QsIFZvbCAxICMzMzMg LSAxIG1zZw0KDQoNCj4gSGksIERvcm90aHkNCj4gDQo+IG1heSBpIGhhdmUgc29tZSBkaXNjdXNz aW9uIHdpdGggeW91IG9uIHRoZSBDdXN0b20gUmVxdWlyZW1lbnRzIHNlY3Rpb24gaW4gZWFjaCBy ZXF1aXJlbWVudD8NCj4gDQo+ID4gMS4gKGdlbmVyYWwpICBDdXN0b21lciBSZXF1aXJlbWVudHMg c2VjdGlvbiBzaG91bGQgbm90IGJlIGEgc3ViLXNlY3Rpb24gPQ0KPiA+IG9mIGVhY2ggT2JqZWN0 aXZlLCBidXQgcmF0aGVyIGEgc2VwYXJhdGUgc2VjdGlvbiBmb3IgU2VydmljZSBQcm92aWRlcnMg PQ0KPiA+IHRvIGxpc3QgdGhlaXIgcmVxdWlyZW1lbnRzLiAgQXMgdGhlIGRyYWZ0J3MgYXV0aG9y IGxpc3QgaW5jbHVkZXMgPQ0KPiA+IE9wZXJhdG9ycywgdGhpcyBzZWN0aW9uIHNob3VsZCBsaXN0 IE9wZXJhdG9yIFNwZWNpZmljIHJlcXVpcmVtZW50cyB0aGF0ID0NCj4gPiBtYXkgYmUgbWlzc2Vk IGJ5IGVxdWlwbWVudCB2ZW5kb3JzLiA9MjANCj4gPiANCj4gDQo+IE15IHVuZGVyc3RhbmRpbmcg b2YgdGhlIEN1c3RvbWVyIFJlcXVpcmVtZW50cyBzZWN0aW9uIGluIGVhY2ggcmVxdWlyZW1lbnQg aXMgdG8gZ2l2ZSB3aGF0IHdpbGwgYmUgbWV0IGJ5IGltcGxlbWVudGluZyBpdCBvciB0aGUgdGhl IGJlbmVmaXQgb2YgdGhlIHJlcXVpcmVtZW50IHRvIHRoZSBjdXN0b21lcnMuIEluIGZhY3QsIGFs bCBvZiB0aGUgYXJjaGl0ZWN0dXJlLCBvcGVyYXRpb25hbCBhbmQgc2VjdXJpdHkgcmVxdWlyZW1l bnRzIGNhbiBiZSB1bmRlcnN0b29kIGFzIGN1c3RvbWVyIHJlcXVpcmVtZW50cy4NCj4gDQo+IHNv IGkgZ3Vlc3MgaWYgeW91IG5lZWQgdGhlIHNlcGVyYXRlIHNlY3Rpb24gb2YgQ3VzdG9tZXIgUmVx dWlyZW1lbnQgdGhhdCBnaXZlcyBoaWdoZXIgbGV2ZWwgcmVxdWlyZW1lbnQgdGhhbiB0aG9zZSBn aXZlbiBvbmUgYnkgb25lIGluIHRoZSBkcmFmdD8NCj4gDQo+IGNvdWxkIHlvdSBwbHMuIGdpdmUg dXMgc29tZSBjbGFyaWZpY2F0aW9uIG9uIGl0PyB0aGFua3MuDQo+IA0KPiBCci56aG91IHdlbmh1 aQ0KPiBTZW5pb3IgUHJvamVjdCBNYW5hZ2VyLA0KPiBSJkQgQ2VudGVyLA0KPiBDaGluYSBNb2Jp bGUNCj4gDQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPiBGcm9tOiA8Y2Fw d2FwLXJlcXVlc3RAZnJhc2NvbmUuY29tPg0KPiBUbzogPGNhcHdhcEBmcmFzY29uZS5jb20+DQo+ IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNywgMjAwNSAxOjAwIEFNDQo+IFN1YmplY3Q6IENh cHdhcCBkaWdlc3QsIFZvbCAxICMzMzMgLSAxIG1zZw0KPiANCj4gDQo+ID4gU2VuZCBDYXB3YXAg bWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQo+ID4gY2Fwd2FwQGZyYXNjb25lLmNvbQ0KPiA+ IA0KPiA+IFRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2Vi LCB2aXNpdA0KPiA+IGh0dHA6Ly9tYWlsLmZyYXNjb25lLmNvbS9tYWlsbWFuL2xpc3RpbmZvL2Nh cHdhcA0KPiA+IG9yLCB2aWEgZW1haWwsIHNlbmQgYSBtZXNzYWdlIHdpdGggc3ViamVjdCBvciBi b2R5ICdoZWxwJyB0bw0KPiA+IGNhcHdhcC1yZXF1ZXN0QGZyYXNjb25lLmNvbQ0KPiA+IA0KPiA+ IFlvdSBjYW4gcmVhY2ggdGhlIHBlcnNvbiBtYW5hZ2luZyB0aGUgbGlzdCBhdA0KPiA+IGNhcHdh cC1hZG1pbkBmcmFzY29uZS5jb20NCj4gPiANCj4gPiBXaGVuIHJlcGx5aW5nLCBwbGVhc2UgZWRp dCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljDQo+ID4gdGhhbiAiUmU6 IENvbnRlbnRzIG9mIENhcHdhcCBkaWdlc3QuLi4iDQo+ID4gDQo+ID4gDQo+ID4gVG9kYXkncyBU b3BpY3M6DQo+ID4gDQo+ID4gICAgMS4gQ29tbWVudHMgb24gQ0FQV0FQIE9iamVjdGl2ZXMgZHJh ZnQgKERvcm90aHkuR2VsbGVydEBub2tpYS5jb20pDQo+ID4gDQo+ID4gLS1fXy0tX18tLQ0KPiA+ IA0KPiA+IE1lc3NhZ2U6IDENCj4gPiBEYXRlOiBUdWUsIDE1IEZlYiAyMDA1IDE1OjU2OjEyIC0w ODAwDQo+ID4gRnJvbTogPERvcm90aHkuR2VsbGVydEBub2tpYS5jb20+DQo+ID4gVG86IDxjYXB3 YXBAZnJhc2NvbmUuY29tPg0KPiA+IENjOiA8bW1hbmlAYXZheWEuY29tPiwgPERvcm90aHkuR2Vs bGVydEBub2tpYS5jb20+DQo+ID4gU3ViamVjdDogW0NhcHdhcF0gQ29tbWVudHMgb24gQ0FQV0FQ IE9iamVjdGl2ZXMgZHJhZnQNCj4gPiANCj4gPiANCj4gPiBIZXJlIGFyZSBzb21lIGNvbW1lbnRz IHRoZSBjaGFpcnMgaGF2ZSBvbiB0aGUgT2JqZWN0aXZlcyBkcmFmdC4gIFdlIGFsc28gPQ0KPiA+ IHByb3ZpZGVkIHByaW9yaXR5IGNsYXNzaWZpY2F0aW9ucyBmb3IgZWFjaCBvYmplY3RpdmUgYXMg ZGVzY3JpYmVkIGluIHRoZSA9DQo+ID4gY2hhcnRlci4gIEkgaG9wZSB0aGlzIGdlbmVyYXRlcyBz b21lIGRpc2N1c3Npb24gYW5kIG1vcmUgY29tbWVudHMuID0yMA0KPiA+IA0KPiA+IEtlZXAgaW4g bWluZCB0aGF0IHdlIGFyZSBsb29raW5nIGZvciBhIG1pbmltYWwgc2V0IG9mIHJlcXVpcmVtZW50 cyA9DQo+ID4gbmVlZGVkIGZvciBhbiBpbnRlcm9wZXJhYmxlIHByb3RvY29sLiAgPTIwDQo+ID4g DQo+ID4gUmVnYXJkcywNCj4gPiBEb3JvdGh5DQo+ID4gDQo+ID4gDQo+ID4gMS4gKGdlbmVyYWwp ICBDdXN0b21lciBSZXF1aXJlbWVudHMgc2VjdGlvbiBzaG91bGQgbm90IGJlIGEgc3ViLXNlY3Rp b24gPQ0KPiA+IG9mIGVhY2ggT2JqZWN0aXZlLCBidXQgcmF0aGVyIGEgc2VwYXJhdGUgc2VjdGlv biBmb3IgU2VydmljZSBQcm92aWRlcnMgPQ0KPiA+IHRvIGxpc3QgdGhlaXIgcmVxdWlyZW1lbnRz LiAgQXMgdGhlIGRyYWZ0J3MgYXV0aG9yIGxpc3QgaW5jbHVkZXMgPQ0KPiA+IE9wZXJhdG9ycywg dGhpcyBzZWN0aW9uIHNob3VsZCBsaXN0IE9wZXJhdG9yIFNwZWNpZmljIHJlcXVpcmVtZW50cyB0 aGF0ID0NCj4gPiBtYXkgYmUgbWlzc2VkIGJ5IGVxdWlwbWVudCB2ZW5kb3JzLiA9MjANCj4gPiAN Cj4gPiAyLiAoZ2VuZXJhbCkgIFNvbWUgb2YgdGhlIE9iamVjdGl2ZSBTZWN0aW9uIGluY2x1ZGUg c3Vic2VjdGlvbi4gIFRoZXNlID0NCj4gPiBzaG91bGQgYmUgcHVsbGVkIG91dCBzbyB3ZSBjYW4g cHJpb3JpdGl6ZSB0aGVtIG9uIHRoZWlyIG93biBtZXJpdC4NCj4gPiAgRXhhbXBsZTogIDUuMi4z LmksIGlpLCBpaWksIDUuMi40LmksIGlpLCBpaWksIDUuMi41LmksIGlpDQo+ID4gDQo+ID4gMy4g KGdlbmVyYWwpICBXZSBuZWVkIHRvIGNsZWFybHkgc3RhdGUgdGhlIFJlcXVpcmVtZW50IGluIGVh Y2ggPQ0KPiA+IG9iamVjdGl2ZS4gIEkgZG9uJ3QgYmVsaWV2ZSB0aGUgdGl0bGUgb2YgdGhlIG9i amVjdGl2ZSBpcyBlbm91Z2guICBUaGUgPQ0KPiA+IHdheSBpdHMgc3RhdGVkIG5vdyB3ZSBoYXZl IHRvIHN1cm1pc2UgdGhlIHJlcXVpcmVtZW50IGZyb20gdGhlID0NCj4gPiBkZXNjcmlwdGlvbi4g PTIwDQo+ID4gDQo+ID4gNC4gKGdlbmVyYWwpICBTZWN0aW9uIDUuMyBuZWVkcyB0byBiZSBtb3Zl ZCBpbnRvIHRoZSBpbnRybyBzZWN0aW9uLg0KPiA+IA0KPiA+IE9iamVjdGl2ZTogNS4yLjMuaTog IExvZ2ljYWwgR3JvdXBzLCBQcmlvcml0eTogIE1hbmRhdG9yeQ0KPiA+IE9iamVjdGl2ZSA1LjIu My5paTogIFNob3VsZCB0aGlzIGJlIE11dHVhbCBFeGNsdXNpb24gb2YgQ29udHJvbCBhbmQgPQ0K PiA+IERhdGE/ICBQcmlvcml0eTogIE1hbmRhdG9yeQ0KPiA+IE9iamVjdGl2ZSA1LjIuMy5paWk6 ICBNdWx0aXBsZSBBdXRoZW50aWNhdGlvbiBNZWNoYW5pc21zOiAgRGVzaXJhYmxlLiA9MjANCj4g PiAtIDgwMi4xMWkgc2hvdWxkIGJlIHJlcXVpcmVtZW50LCBub3QgYW4gb3B0aW9uLiA9MjANCj4g PiANCj4gPiBPYmplY3RpdmUgNS4yLjQuaTogIEVuYWJsZSBzdXBwb3J0IGZvciBmdXR1cmUgd2ly ZWxlc3MgdGVjaG5vbG9naWVzOiAgPQ0KPiA+IERlc2lyYWJsZQ0KPiA+IC0gODAyLjExIGZpcnN0 LCA4MDIuMTYgcmVxdWlyZW1lbnRzIGluIHBoYXNlIDEgdGltZSBwZXJtaXR0aW5nLiAgQXMgPQ0K PiA+IHN0YXRlZCBpbiBDaGFydGVyLg0KPiA+IE9iamVjdGl2ZSA1LjIuNC5paTogIEVuYWJsZSBz dXBwb3J0IGZvciBuZXcgSUVFRSByZXF1aXJlbWVudHM6IERlc2lyYWJsZQ0KPiA+IE9iamVjdGl2 ZSA1LjIuNC5paWkgIEFjY2VzcyBSZXF1aXJlbWVudHM6ICBEbyB5b3UgbWVhbiB0cmFuc3BhcmVu Y3kgPQ0KPiA+IGhlcmU/ICBUaGlzIGlzIHVuY2xlYXIuICBUcmFuc3BhcmVuY3kgc2hvdWxkIGJl IE1hbmRhdG9yeQ0KPiA+IA0KPiA+IE9iamVjdGl2ZSA1LjIuNS5pOiAgQ29uZmlndXJhdGlvbiBD b25zaXN0ZW5jeTogIFByaW9yaXR5OiAgTWFuZGF0b3J5PTIwDQo+ID4gLSBJcyB0aGUgcmVxdWly ZW1lbnQgdG8gdXBkYXRlIGNvbmZpZ3VyYXRpb24gaW5mbyB0byBBQz8gIERvIHlvdSBtZWFuID0N Cj4gPiB0byBnZXQgaW50byBQcm92aXNpb25pbmcgaGVyZT8gPTIwDQo+ID4gLSBmaXJtd2FyZSBk aXN0cmlidXRpb24gbmVlZHMgdG8gYmUgaXRzIG93biByZXF1aXJlbWVudC4gIFNob3VsZCB0aGlz ID0NCj4gPiBiZSBvbiBjb250cm9sIG9yIGRhdGEgcGxhbmU/PTIwDQo+ID4gT2JqZWN0aXZlIDUu Mi41LmlpOiAgU3lzdGVtIFdpZGUgcmVzb3VyY2Ugc3RhdGU6ICBQcmlvcml0eSBNYW5kYXRvcnkN Cj4gPiAtIERlZmluZSB3aGF0IHN0YXRpc3RpY3MgYXJlIG5lZWRlZC4NCj4gPiA9MDkNCj4gPiBP YmplY3RpdmUgNS4yLjY6ICBSZXNvdXJjZSBDb250cm9sIE9iamVjdGl2ZXM6ICBQcmlvcml0eTog IE1hbmRhdG9yeQ0KPiA+IC0gUmVxdWlyZW1lbnQgaXMgdG8gbWFpbnRhaW4gdGhlIDgwMi4xMWUg bWFwcGluZy4gIENhbiB0aGlzIGJlID0NCj4gPiBleHBhbmRlZCB0byBpbmNsdWRlIG90aGVyIDgw Mi4xMSBURyBzZW1hbnRpY3M/DQo+ID4gDQo+ID4gT2JqZWN0aXZlIDUuMi43IFRyYWZmaWMgU2Vw YXJhdGlvbjogPTIwDQo+ID4gSXNuJ3QgdGhpcyBhIGR1cGxpY2F0ZSBvZiA1LjIuMy5paT8NCj4g PiANCj4gPiBPYmplY3RpdmUgNS4yLjg6ICBTVEEgQWRtaXNzaW9uIENvbnRyb2wgT2JqZWN0aXZl cyAgPTA5DQo+ID4gLSBOZWVkIHRvIGJlIGJldHRlciBkZWZpbmVkLiAgRG9uJ3Qga25vdyB3aGF0 IHlvdSBhcmUgZ2V0dGluZyBhdCA9DQo+ID4gaGVyZS4NCj4gPiANCj4gPiBPYmplY3RpdmUgNS4y Ljk6ICBDZW50cmFsaXplZCBXVFAgTWFuYWdlbWVudDoNCj4gPiAtIElzbid0IHRoaXMgYSBkdXBs aWNhdGUgb2YgNS4yLjUuaT8NCj4gPiANCj4gPiBPYmplY3RpdmUgNS4yLjEwOiAgQ0FQV0FQIFBy b3RvY29sIFNlY3VyaXR5OiAgUHJpb3JpdHk6ICBNYW5kYXRvcnkgPTIwDQo+ID4gLSBJcyB0aGlz IG11dHVhbCBhdXRoZW50aWNhdGlvbiwgc2hvdWxkIGJlIGNsYXJpZmllZA0KPiA+IA0KPiA+IE9i amVjdGl2ZXMgNS4yLjExOiAgU3lzdGVtIFdpZGUgU2VjdXJpdHkgOiBQcmlvcml0eTogIE1hbmRh dG9yeQ0KPiA+IA0KPiA+IE9iamVjdGl2ZXMgNS4yLjEyOiAgQ2VudHJhbGl6ZWQgV1RQIG1hbmFn ZW1lbnQ6ICBQcmlvcml0eTogIFJlamVjdGVkDQo+ID4gLSBJdCBzb3VuZHMgbGlrZSB5b3UgYXJl IHJlcXVlc3RpbmcgdGhlIEFDIG5vdCBwYXJ0aWNpcGF0ZSBpbiA9DQo+ID4gbWFuYWdlbWVudC4g IFRoaXMgZG9lc24ndCBzZWVtIHJlbGV2YW50IHRvIGVzdGFibGlzaGluZyBhIGNvbnRyb2wgYW5k ID0NCj4gPiBwcm92aXNpb25pbmcgcHJvdG9jb2wgZm9yIEFQcy4gQXQgdGhlIHZlcnkgbGVhc3Qg aXQgZG9lc24ndCBzZWVtIGxpa2UgYSA9DQo+ID4gaGlnaCBwcmlvcml0eSByZXF1aXJlbWVudCBm b3IgYSBwaGFzZSAxIENBUFdBUCBwcm90b2NvbC4gPTIwDQo+ID4gDQo+ID4gT2JqZWN0aXZlczog IDUuMi4xMzogIFNlY3VyaXR5IEJvcmRlcmxpbmUgQ29udHJvbDogIFByaW9yaXR5OiAgRGVzaXJh YmxlID0NCj4gPiANCj4gPiAtIElzIHRoaXMgbmVjZXNzYXJ5IGZvciBhIHBoYXNlIDEgQ0FQV0FQ IHByb3RvY29sPw0KPiA+IA0KPiA+IE9iamVjdGl2ZSA1LjIuMTQ6ICBUcnVzdCBNb2RlbCBEZWZp bml0aW9ucw0KPiA+IC0gSXMgdGhpcyBhIGR1cGxpY2F0ZSBvZiBtdXR1YWwgYXV0aGVudGljYXRp b24gaW4gNS4yLjEwPyA9MjANCj4gPiANCj4gPiBPYmplY3RpdmVzIDUuMi4xNTogICBJRUVFIDgw Mi4xMWkgQ29uc2lkZXJhdGlvbnMNCj4gPiAtV2hhdCBpcyB0aGUgcHJvcG9zYWwgZm9yIGtleSBk aXN0cmlidXRpb24gaW4gZWFjaCBjYXNlPyAgIFByaW9yaXR5ID0NCj4gPiBNYW5kYXRvcnkgKGZv ciBrZXkgZGlzdHJpYnV0aW9uIG9ubHkpDQo+ID4gLVdoYXQgb3RoZXIgY29uc2lkZXJhdGlvbnM/ DQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ ID4gDQo+ID4gDQo+ID4gDQo+ID4gLS1fXy0tX18tLQ0KPiA+IA0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gQ2Fwd2FwIG1haWxpbmcgbGlz dA0KPiA+IENhcHdhcEBmcmFzY29uZS5jb20NCj4gPiBodHRwOi8vbWFpbC5mcmFzY29uZS5jb20v bWFpbG1hbi9saXN0aW5mby9jYXB3YXANCj4gPiANCj4gPiANCj4gPiBFbmQgb2YgQ2Fwd2FwIERp Z2VzdA== _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Mar 3 04:17:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25765 for ; Thu, 3 Mar 2005 04:17:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5214A204BB; Thu, 3 Mar 2005 04:17:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A94D204B2; Thu, 3 Mar 2005 04:17:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DDFBF204B2 for ; Thu, 3 Mar 2005 04:16:49 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 70CD0204A9 for ; Thu, 3 Mar 2005 04:16:46 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j239H0A11846; Thu, 3 Mar 2005 11:17:00 +0200 (EET) X-Scanned: Thu, 3 Mar 2005 11:16:02 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j239G2CK019422; Thu, 3 Mar 2005 11:16:02 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00pSNKqP; Thu, 03 Mar 2005 11:16:00 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j239FxU24316; Thu, 3 Mar 2005 11:15:59 +0200 (EET) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Mar 2005 03:15:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] Re: Capwap digest, Vol 1 #333 - 1 msg Message-ID: Thread-Topic: [Capwap] Re: Capwap digest, Vol 1 #333 - 1 msg Thread-Index: AcUfwifZruOdIM5kRiK926XS+oiGdgACY9FQ From: To: Cc: X-OriginalArrivalTime: 03 Mar 2005 09:15:58.0585 (UTC) FILETIME=[9C995E90:01C51FD1] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 3 Mar 2005 01:15:56 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Zhou, We had some discussion on this during the summer IETF WG meeting. The = customer requirements section were suggested by our AD to capture = specific customer requirements, i.e., those that may have been missed by = an equipment vendor.=20 =20 We were making an effort to make sure that the owner of a large WLAN = deployment had some say in the requirements and that the needs of the = markets were met, and not just needs of the equipment manufacturers. I do expect that all requirements have benefit to the end customer as = they are understood by the vendor. The customer requirement section = was meant for items above and beyond that (interworking dependencies, = 802.15, etc). Mani and I have contacted some large WLAN customers and = have not gotten any response yet. As for the priority being higher... Since we are prioritzing each = requirement, I believe WG consensus its the best way to set the = prioirity, as well as the charter guideline to create a protocol based = on a minimum set of requirements. We have the option of moving = desirable objectives into a separate drafts or later version of the = protocol. I hope this helps. We can talk further about this in Minneapolis. Dorothy -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On = Behalf Of ext Wenhui Zhou Sent: Wednesday, March 02, 2005 11:13 PM To: capwap@frascone.com Subject: [Capwap] Re: Capwap digest, Vol 1 #333 - 1 msg Hi, Dorothy may i have some discussion with you on the Custom Requirements section = in each requirement? > 1. (general) Customer Requirements section should not be a = sub-section =3D > of each Objective, but rather a separate section for Service Providers = =3D > to list their requirements. As the draft's author list includes =3D > Operators, this section should list Operator Specific requirements = that =3D > may be missed by equipment vendors. =3D20 >=20 My understanding of the Customer Requirements section in each = requirement is to give what will be met by implementing it or the the = benefit of the requirement to the customers. In fact, all of the = architecture, operational and security requirements can be understood as = customer requirements. so i guess if you need the seperate section of Customer Requirement that = gives higher level requirement than those given one by one in the draft? could you pls. give us some clarification on it? thanks. Br.zhou wenhui Senior Project Manager, R&D Center, China Mobile ----- Original Message -----=20 From: To: Sent: Thursday, February 17, 2005 1:00 AM Subject: Capwap digest, Vol 1 #333 - 1 msg > Send Capwap mailing list submissions to > capwap@frascone.com >=20 > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.frascone.com/mailman/listinfo/capwap > or, via email, send a message with subject or body 'help' to > capwap-request@frascone.com >=20 > You can reach the person managing the list at > capwap-admin@frascone.com >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Capwap digest..." >=20 >=20 > Today's Topics: >=20 > 1. Comments on CAPWAP Objectives draft (Dorothy.Gellert@nokia.com) >=20 > --__--__-- >=20 > Message: 1 > Date: Tue, 15 Feb 2005 15:56:12 -0800 > From: > To: > Cc: , > Subject: [Capwap] Comments on CAPWAP Objectives draft >=20 >=20 > Here are some comments the chairs have on the Objectives draft. We = also =3D > provided priority classifications for each objective as described in = the =3D > charter. I hope this generates some discussion and more comments. = =3D20 >=20 > Keep in mind that we are looking for a minimal set of requirements =3D > needed for an interoperable protocol. =3D20 >=20 > Regards, > Dorothy >=20 >=20 > 1. (general) Customer Requirements section should not be a = sub-section =3D > of each Objective, but rather a separate section for Service Providers = =3D > to list their requirements. As the draft's author list includes =3D > Operators, this section should list Operator Specific requirements = that =3D > may be missed by equipment vendors. =3D20 >=20 > 2. (general) Some of the Objective Section include subsection. These = =3D > should be pulled out so we can prioritize them on their own merit. > Example: 5.2.3.i, ii, iii, 5.2.4.i, ii, iii, 5.2.5.i, ii >=20 > 3. (general) We need to clearly state the Requirement in each =3D > objective. I don't believe the title of the objective is enough. The = =3D > way its stated now we have to surmise the requirement from the =3D > description. =3D20 >=20 > 4. (general) Section 5.3 needs to be moved into the intro section. >=20 > Objective: 5.2.3.i: Logical Groups, Priority: Mandatory > Objective 5.2.3.ii: Should this be Mutual Exclusion of Control and = =3D > Data? Priority: Mandatory > Objective 5.2.3.iii: Multiple Authentication Mechanisms: Desirable. = =3D20 > - 802.11i should be requirement, not an option. =3D20 >=20 > Objective 5.2.4.i: Enable support for future wireless technologies: = =3D > Desirable > - 802.11 first, 802.16 requirements in phase 1 time permitting. As = =3D > stated in Charter. > Objective 5.2.4.ii: Enable support for new IEEE requirements: = Desirable > Objective 5.2.4.iii Access Requirements: Do you mean transparency = =3D > here? This is unclear. Transparency should be Mandatory >=20 > Objective 5.2.5.i: Configuration Consistency: Priority: = Mandatory=3D20 > - Is the requirement to update configuration info to AC? Do you mean = =3D > to get into Provisioning here? =3D20 > - firmware distribution needs to be its own requirement. Should this = =3D > be on control or data plane?=3D20 > Objective 5.2.5.ii: System Wide resource state: Priority Mandatory > - Define what statistics are needed. > =3D09 > Objective 5.2.6: Resource Control Objectives: Priority: Mandatory > - Requirement is to maintain the 802.11e mapping. Can this be =3D > expanded to include other 802.11 TG semantics? >=20 > Objective 5.2.7 Traffic Separation: =3D20 > Isn't this a duplicate of 5.2.3.ii? >=20 > Objective 5.2.8: STA Admission Control Objectives =3D09 > - Need to be better defined. Don't know what you are getting at =3D > here. >=20 > Objective 5.2.9: Centralized WTP Management: > - Isn't this a duplicate of 5.2.5.i? >=20 > Objective 5.2.10: CAPWAP Protocol Security: Priority: Mandatory = =3D20 > - Is this mutual authentication, should be clarified >=20 > Objectives 5.2.11: System Wide Security : Priority: Mandatory >=20 > Objectives 5.2.12: Centralized WTP management: Priority: Rejected > - It sounds like you are requesting the AC not participate in =3D > management. This doesn't seem relevant to establishing a control and = =3D > provisioning protocol for APs. At the very least it doesn't seem like = a =3D > high priority requirement for a phase 1 CAPWAP protocol. =3D20 >=20 > Objectives: 5.2.13: Security Borderline Control: Priority: = Desirable =3D >=20 > - Is this necessary for a phase 1 CAPWAP protocol? >=20 > Objective 5.2.14: Trust Model Definitions > - Is this a duplicate of mutual authentication in 5.2.10? =3D20 >=20 > Objectives 5.2.15: IEEE 802.11i Considerations > -What is the proposal for key distribution in each case? Priority = =3D > Mandatory (for key distribution only) > -What other considerations? >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --__--__-- >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 >=20 > End of Capwap Digest j=8A=82=B4=C1=AD=A2=A2=B6=99~rr=99=99=96=8A _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Mar 3 12:29:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21356 for ; Thu, 3 Mar 2005 12:29:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 84E802036C; Thu, 3 Mar 2005 12:29:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D861420397; Thu, 3 Mar 2005 12:29:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8C96C20397 for ; Thu, 3 Mar 2005 12:28:29 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 83B6A2036C for ; Thu, 3 Mar 2005 12:28:26 -0500 (EST) Message-ID: <069501c52016$8e933ab0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Saravanan Govindan" , "'subrata goswami'" Cc: References: <200503030216.j232GG3O003806@mailsrv.psl.com.sg> Subject: Re: [Capwap] Additional Requirement? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 3 Mar 2005 09:29:21 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit This sounds OK, but I'm wondering if anything other than IP needs to be mentioned. With a very few exceptions (PPP, MPLS, EAP), IETF typically doesn't deal with standardizing anything other than IP. I assume CAPWAP won't be proposing running over anything other than IP, or? And if something runs over IP, it should run just fine over Ethernet, ATM, etc., so why even mention them? What I suspect might be the real concern here (and please correct me if I am wrong) is to avoid desigining the protocol such that it only works over a single hop Ethernet or within a closed administrative domain. So if the protocol only ran over 802.3 Ethernet, it could only be used over a single hop, between a router and the AC/WTPs on the link. It is possible to design the protocol using IP and still have it constrained to a single hop, or make it insecure to use on anything other than a single hop. To avoid this, the paragraph should have something in it specifying that the protocol should run over networks that are both tightly administered and public access. I'd propose modifying the paragraph to say: "As a result of realizing this objective, the protocol will be capable of operation over both IPv4 and IPv6, and will be designed such that it can run on single hop links, within tightly administered networks, such as enterprise networks, or on open, public access networks." jak ----- Original Message ----- From: "Saravanan Govindan" To: "'James Kempf'" ; "'subrata goswami'" Cc: Sent: Wednesday, March 02, 2005 6:19 PM Subject: RE: [Capwap] Additional Requirement? > Hi James, > > Apologies for the late reply. > > It is a good point you raise that CAPWAP needs to be able to run independent of IP versions. > > The Interconnection objective (5.2.6) tries to capture this requirement. It suggests that the CAPWAP > protocol be independent of underlying transport technology. Maybe we can add IPv4 and IPv6 > specifically as transport technologies that the protocol must be independent of. > > Consider revising the paragraph 2 of the Description (5.2.6), last sentence: > > Current text: > > "As a result of realizing this objective, the protocol will be capable of operation over different > interconnect technologies including Ethernet, bus backplanes, ATM (cell) fabrics and also wireless > technologies such as IEEE 802.11." > > Proposed text: > > "As a result of realizing this objective, the protocol will be capable of operation over different > interconnect technologies including Ethernet, IPv4, IPv6, bus backplanes, ATM (cell) fabrics and > also wireless technologies such as IEEE 802.11." > > Does this capture your suggestion for IP version independence? > > Cheers, > > Saravanan > > > > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > > Sent: Friday, February 25, 2005 2:26 AM > > To: subrata goswami; Saravanan Govindan > > Cc: capwap@frascone.com > > Subject: [Capwap] Additional Requirement? > > > > I don't recall seeing anything about independence of IP > > version. I think CAPWAP needs to be defined such that it will > > run on IPv4 or IPv6. > > > > jak > > > > ----- Original Message ----- > > From: "subrata goswami" > > To: "Saravanan Govindan" > > Cc: ; > > Sent: Thursday, February 24, 2005 8:33 AM > > Subject: Re: [Capwap] Additions #12 - Future Wireless Technologies > > > > > > > Saravanan , seems okay to me. > > > > > > Subrata > > > > > > > > > Saravanan Govindan wrote: > > > > > > >Hi Subrata, James, > > > > > > > >Thank you for your comments and suggestions. > > > > > > > >In summary, the suggestion is to clearly specify what the > > CAPWAP protocol > > needs in terms of > > > >applicability to 802.11 and non-802.11 technologies. > > > > > > > >Please consider the following text which combines the > > proposals from > > James and Subrata. > > > > > > > >------- > > > >(Include the following in Description) > > > > > > > >"In all cases where the CAPWAP protocol messages contain > > specific Layer 2 > > information elements, the > > > >definition of the protocol needs to provide for > > extensibility so that > > these elements can be defined > > > >for specific layer 2 wireless protocols. This may entail > > assigning a > > layer 2 wireless protocol type > > > >and version field to the message PDU. Examples of other wireless > > protocols that might be supported > > > >include but are not limited to 802.16e, 802.15.x, etc." > > > >----XXXX---- > > > > > > > >Cheers, > > > > > > > >Saravanan > > > > > > > > > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > > > >>From: capwap-admin@frascone.com > > > >>[mailto:capwap-admin@frascone.com] On Behalf Of James Kempf > > > >>Sent: Thursday, February 24, 2005 1:57 AM > > > >>To: subrata goswami; capwap@frascone.com > > > >>Subject: Re: [Capwap] Additions #12 - Future Wireless Technologies > > > >> > > > >> > > > >> > > > >> > > > >>>>"In all cases where the CAPWAP protocol messages > > contain specific > > > >>>>Layer 2 information elements, the definition of the > > > >>>> > > > >>>> > > > >>protocol needs to > > > >> > > > >> > > > >>>>provide for extensibility so that these elements can be > > > >>>> > > > >>>> > > > >>defined for > > > >> > > > >> > > > >>>>wireless > > > >>>> > > > >>>> > > > >>protocols > > > >> > > > >> > > > >>>>other than 802.11." > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>"In all cases where the CAPWAP protocol messages contain specific > > > >>>Layer 2 information elements, the definition of the > > > >>> > > > >>> > > > >>protocol needs to > > > >> > > > >> > > > >>>provide for extensibility so that these elements can be > > defined for > > > >>>specific layer 2 wireless protocols (e.g. 802.11, > > 802.16, 802.15.x > > > >>>etc). This may > > > >>> > > > >>> > > > >>The problem with mentioning these is it might be construed to > > > >>exclude others. If you want to include specific reference, > > > >>I'd suggest adding a sentence at the end of the paragraph > > > >>that says something like: > > > >> > > > >>"Examples of other wireless protocols that might be supported > > > >>include but are not limited to 802.16e, 802.15.x, etc. > > > >> > > > >> > > > >> > > > >>>entail assigning a layer 2 wireless protocol type and > > > >>> > > > >>> > > > >>version field to > > > >> > > > >> > > > >>>the message PDU. " > > > >>> > > > >>> > > > >>> > > > >>Hmm, well, that's a bit too specific for a requirement. But, > > > >>off the top of my head, I can't think of any other way one > > > >>could do this, so I suppose it's OK. > > > >> > > > >> jak > > > >> > > > >> > > > >> > > > >>_______________________________________________ > > > >>Capwap mailing list > > > >>Capwap@frascone.com > > > >>http://mail.frascone.com/mailman/listinfo/capwap > > > >> > > > >> > > > >> > > > > > > > >_______________________________________________ > > > >Capwap mailing list > > > >Capwap@frascone.com > > > >http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 4 16:37:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07626 for ; Fri, 4 Mar 2005 16:37:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 51F7420647; Fri, 4 Mar 2005 16:37:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A6812063C; Fri, 4 Mar 2005 16:37:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 940B72063C for ; Fri, 4 Mar 2005 16:36:32 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by mail.frascone.com (Postfix) with ESMTP id 631A72063B for ; Fri, 4 Mar 2005 16:36:26 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 67so2133134wri for ; Fri, 04 Mar 2005 13:36:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=ZZxAf+h0cJLFY9UavukePX9iluvP+r3vdPlF5sLtUBdscjxMhEzjmgE/4yfCNYOm1x7L1PGsjjVWcU7BHwmET6UI8ixHPG7xNLqIIxy+OpcTimyPJ8yoIUR7utYflQ4dhFqimTSddlTf6vsB6LrkO8hhHmd0u8BMkLVe5tdDRbc= Received: by 10.54.63.5 with SMTP id l5mr76188wra; Fri, 04 Mar 2005 13:36:21 -0800 (PST) Received: by 10.54.49.27 with HTTP; Fri, 4 Mar 2005 13:36:21 -0800 (PST) Message-ID: From: Inderpreet Singh Reply-To: Inderpreet Singh To: capwap@frascone.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Comments on objectives draft Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 4 Mar 2005 16:36:21 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I have had trouble with getting email through to the capwap list for a while. I just had a couple of comments. ---- Cheng Hong wrote earlier: >>If that is still too much, we can modify the charter to clearly state >>which types of architecture should be in scope of CAPWAP (and forget >>about all the other permutations). I think the charter is quite clear on what the objective should be. "The revised CAPWAP WG will reference two classes of the Centralized WLAN Architecture family, namely the Local MAC and the Split MAC, as described in the CAPWAP Architecture Taxonomy draft." Emek Sadot wrote earlier: >>The other side of the coin is the question how many permutations would >>the protocol allows within each group - Split and Local. E.g. does >>the protocol allows the existent of several distinct Split WTPs each >>with different (APF) set of components? Once again, the charter is clear and does not mention multiple permutations within each architecture family. Local MAC is Local MAC. Split MAC is Split MAC. I don't know of any variations in implementations of Local MAC. If there are variations within Split MAC I suggest that defining the final form of Split MAC be out of scope for CAPWAP. Nevertheless, IMHO any CAPWAP protocol that is developed must include a capabilities exchange that just goes as far as defining Local MAC or Split MAC for the data path - not permutations within. Thanks Inderpreet _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Mar 7 01:44:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16570 for ; Mon, 7 Mar 2005 01:44:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D79932035A; Mon, 7 Mar 2005 01:44:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C77B2031A; Mon, 7 Mar 2005 01:44:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B01A62031A for ; Mon, 7 Mar 2005 01:44:00 -0500 (EST) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 90502202CA for ; Mon, 7 Mar 2005 01:43:57 -0500 (EST) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j276fjED029335 for ; Mon, 7 Mar 2005 01:41:45 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j276fiED029307 for ; Mon, 7 Mar 2005 01:41:44 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C522E1.0D0F7A12" x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: Thread-Topic: Final Agenda for Monday session - Minneapolis Thread-Index: AcUi4OnTrN1Pgmf5ShqfQnQlE75A/A== From: "Mani, Mahalingam (Mahalingam)" To: Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Final Agenda for Monday session - Minneapolis Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Sun, 6 Mar 2005 23:44:03 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C522E1.0D0F7A12 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following is the agenda: =20 15:30: Agenda Bashing 15:35: Milestone Update and Progress - Chairs 15:50: IEEE AP Functions Adhoc Committee (and other relevant) Updates - Dorothy Stanley 16:00: Objective draft Issues and Discussion - Saravanan Govindan 16:45: LWAPP Protocol - Pat Calhoun 17:00: CTP Protocol - Inderpreet Singh =20 Inderpreet's Draft (expired and likely to be re-issued after the IETF repository unlock) is available as above.=20 =20 the presentations will be made available at the CAPWAP website - where possible - before the sessions. =20 Regards, -mani =3D=3D=3D=3D=3D=3D =20 ------_=_NextPart_001_01C522E1.0D0F7A12 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The following is the = agenda:

 

15:30:   Agenda = Bashing

15:35:   Milestone Update and Progress = – Chairs

15:50:   IEEE AP Functions Adhoc Committee = (and other relevant) Updates  - Dorothy = Stanley

16:00:   Objective draft Issues and = Discussion – Saravanan Govindan

16:45:   LWAPP Protocol – Pat Calhoun

17:00:   CTP = Protocol -   Inderpreet Singh

 

Inderpreet’s Draft (expired and likely to be = re-issued after the IETF repository unlock) is = available

as above.

 

the presentations will be made available at the = CAPWAP website – where possible = – before the sessions.

 

Regards,

-mani

=3D=3D=3D=3D=3D=3D

 

------_=_NextPart_001_01C522E1.0D0F7A12-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Mar 8 14:36:13 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05337 for ; Tue, 8 Mar 2005 14:36:11 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1D6E20475; Tue, 8 Mar 2005 14:36:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 17AB82045A; Tue, 8 Mar 2005 14:36:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B674C2045A for ; Tue, 8 Mar 2005 14:35:25 -0500 (EST) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id A387F2044C for ; Tue, 8 Mar 2005 14:35:22 -0500 (EST) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j28JP5vn023880 for ; Tue, 8 Mar 2005 14:25:06 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j28JNlvn021920 for ; Tue, 8 Mar 2005 14:24:02 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52415.CC8DD50C" Message-ID: Thread-Topic: Presentations IETF62 Thread-Index: AcUkFaa2uIGMXO/nRIaZwIxliFUE3w== X-Priority: 1 Priority: Urgent Importance: high From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Presentations IETF62 Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 8 Mar 2005 12:34:09 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C52415.CC8DD50C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All CAPWAP session presentations of mar 07, 2005 at Minneapolis are available at http://www.capwap.org/ietf62 =20 Regards, -mani =3D=3D=3D=3D=3D=3D =20 ------_=_NextPart_001_01C52415.CC8DD50C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All CAPWAP session presentations of mar 07, 2005 at = Minneapolis = are available at

http://www.capwap.org/ietf62

 

Regards,

-mani

=3D=3D=3D=3D=3D=3D

 

------_=_NextPart_001_01C52415.CC8DD50C-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 11:59:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25126 for ; Wed, 9 Mar 2005 11:59:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2B7D4202FC; Wed, 9 Mar 2005 11:59:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 858EE2026C; Wed, 9 Mar 2005 11:59:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E19112026C for ; Wed, 9 Mar 2005 11:58:40 -0500 (EST) Received: from aruba-server.arubanetworks.com (216-31-249-252.cust.telepacific.net [216.31.249.252]) by mail.frascone.com (Postfix) with SMTP id B714F20263 for ; Wed, 9 Mar 2005 11:58:36 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: A simpler approach to CAPWAP Thread-Index: AcUkyTkZeOJkvi+lQLCb7JYxtzARZA== From: "Partha Narasimhan" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] A simpler approach to CAPWAP Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 08:58:31 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable The primary reason for the existence of the CAPWAP group is to solve an interoperability problem between ACs and WTPs from different vendors so that an end-user/customer has the choice of purchasing WTPs and ACs from different vendors. The existing marketplace is full of single-vendor solutions. To that extent, if an end-user is able to purchase a WTP from a vendor that is different than the vendor supplying the AC, but get them to interoperate with each other to create a functioning WLAN, then the end-user's objective is largely accomplished. Based on existing single-vendor WLAN solutions, it is obvious that the AC is where most of the control and management intelligence resides. It is not far from the truth to state the AC determines what functions are turned on at the WTPs and, hence, what features are available in the WLAN. Arguably, the interoperability problem can be restated as a customer's need to find WTPs that interoperate with his/her choice of AC. Or at a minimum, the WTPs need to follow and interoperate with the AC rather than the other way around.=20 Interoperability can be achieved at multiple levels. In most of the current discussion on the CAPWAP mailing list, the primary assumption seems to be that interoperability requirement seems to be between the individual software that both the WTP and the AC ship with and/or boot up with. Once both the devices are up and running with their images, the WTPs discover one or more ACs and, assuming everything is set up right, one of the discovered ACs will configure and bring up the WTP as part of the customer's WLAN using a protocol that will be defined as part of the CAPWAP WG's work. Interoperability can also be achieved using a simpler mechanism where a WTP boots up, discovers one or more ACs to create an association with. As part of the discovery process, the WTP identifies itself (vendor ID, hardware version, software version, etc.). One of the discovered ACs can then instruct the WTP to download a firmware image that the WTP should boot itself with at the end of the download process. Upon booting itself with this downloaded image, the WTP runs a protocol, quite possibly proprietary to the AC vendor, contained in the downloaded image to create an association with an AC and get configured to be a member of the WLAN. An AC from one vendor might download an image to a WTP that is completely different than an AC from another vendor. This does solve the end-user's requirement of getting interoperability between WTPs and ACs from different vendors. The control protocol used to get the WTP to become a member of the WLAN controlled and managed by the AC is totally upto the AC vendor's choice. Essentially, the solution becomes a simple protocol for the WTP to discover one or more ACs, identify itself to the ACs, and download an image from the AC, if possible, that it will boot itself with - a secure download problem rather than a WLAN configuration problem from an interoperability perspective. This solves the CAPWAP problem of interoperability without requiring a full-fledged, new control protocol that all the WTP and AC vendors have to implement for interoperability. It is sufficient to implement the simpler secure download protocol to get to interoperability. This removes the necessity to negotiate capabilities (split MAC vs local MAC, one person's split may not suit another but we cannot have infinite permutations of a split, etc.) since the WTP assumes capabilities that are contained in the image that the AC vendor chooses to build for it. Another benefit of this approach is the extensibility of this simpler approach to future wireless technologies or extensions to existing technologies since these are folded into the downloaded image and hence are transparent to the secure download protocol itself. What are the issues with such a secure download protocol? This requires an AC to have a bootable image for every single WTP that the AC wants to interoperate with. Which could be a matter of differentiation for the AC vendors. If one vendor supports 2 models of WTPs, while another one decides to support 10, then the marketplace could choose if they like the feature set of the former enough that they dont mind the reduced set of interoperable WTPs or whether they like the greater interoperability of the latter AC. Secondly, we need a mechanism for the WTP and the AC, soon after the discovery process, to create a trust relationship between each other so that the WTP is sure it is not downloading code from a malicious entity masquerading as an AC and the AC is sure it is not supplying code to an entity masquerading as a WTP.=20 The secure download approach shifts the burden of interoperability to the AC vendors and lowers the barrier for the WTP vendors that strive for interoperability. This shift is fine since the AC is the center of control and management for a WLAN and it is in the AC vendor's interests to get to wider interoperability, if they so chose to do. This is also aligned with the current market reality where the AC vendors' capabilities determine what features are available on the WLAN. The WTP vendors are required to implement a simpler protocol to get to interoperability with multiple AC vendors. The level of interoperability is always determined by individual choices by the vendors. For example, an AC that only supports split MAC may not interoperate with a WTP that only suppports the local MAC. Arguably, the interoperability achievable by the secure download approach is no worse than what is possible with a full-blown control protocol. Not to mention the simplicity of the protocol that the CAPWAP WG needs to work on. We intend to submit a proposal along these lines to the CAPWAP WG. It will involve a simple process as follows: - a WTP discovers one or more ACs, - the WTP identifies itself to the ACs that it discovered, - the WTP and one of the ACs create a mutual trust relationship, and - the WTP downloading an image from an AC. The details will be present in the draft that will follow soon. This approach is quite different from what has been discussed in the WG so far. It probably also has implications on the objectives draft. I would like to initiate some discussion on whether all the mandatory objectives as stated in the current objectives draft are still valid. I understand that the objectives were stated with a full-fledged, open and/or externally verifiable protocol in mind. If a certain set of objectives precludes such a simpler solution then we may need to re-visit and discuss that set of objectives. In other words, if a set of objectives as they currently stand are unnecessary for solving the problem that we started out to address, then we should discuss these now. Thanks partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 13:02:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02277 for ; Wed, 9 Mar 2005 13:02:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 696FE20440; Wed, 9 Mar 2005 13:02:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 70465203A1; Wed, 9 Mar 2005 13:02:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D874203A1 for ; Wed, 9 Mar 2005 13:01:06 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 0210C20393 for ; Wed, 9 Mar 2005 13:01:03 -0500 (EST) Message-ID: <01ce01c524d2$1ac705b0$456015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Partha Narasimhan" , References: Subject: Re: [Capwap] A simpler approach to CAPWAP MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 10:01:57 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Partha, I believe having downloadable firmware is a highly desirable requirement for CAPWAP, to ensure AC- WTP interoperability. However, I do not believe it is a replacement for having an interoperable protocol. From a managability standpoint, I'd like to have a protocol that was standardized among AC vendors, not a bunch of proprietary protocols that would all require different specialized management expertiese (which adds up to OPEX expense). Personally, I don't think restricting CAPWAP goals just to downloadable firmware would fufill the charter, but I'll let it up to the chairs to make the call. jak ----- Original Message ----- From: "Partha Narasimhan" To: Sent: Wednesday, March 09, 2005 8:58 AM Subject: [Capwap] A simpler approach to CAPWAP The primary reason for the existence of the CAPWAP group is to solve an interoperability problem between ACs and WTPs from different vendors so that an end-user/customer has the choice of purchasing WTPs and ACs from different vendors. The existing marketplace is full of single-vendor solutions. To that extent, if an end-user is able to purchase a WTP from a vendor that is different than the vendor supplying the AC, but get them to interoperate with each other to create a functioning WLAN, then the end-user's objective is largely accomplished. Based on existing single-vendor WLAN solutions, it is obvious that the AC is where most of the control and management intelligence resides. It is not far from the truth to state the AC determines what functions are turned on at the WTPs and, hence, what features are available in the WLAN. Arguably, the interoperability problem can be restated as a customer's need to find WTPs that interoperate with his/her choice of AC. Or at a minimum, the WTPs need to follow and interoperate with the AC rather than the other way around. Interoperability can be achieved at multiple levels. In most of the current discussion on the CAPWAP mailing list, the primary assumption seems to be that interoperability requirement seems to be between the individual software that both the WTP and the AC ship with and/or boot up with. Once both the devices are up and running with their images, the WTPs discover one or more ACs and, assuming everything is set up right, one of the discovered ACs will configure and bring up the WTP as part of the customer's WLAN using a protocol that will be defined as part of the CAPWAP WG's work. Interoperability can also be achieved using a simpler mechanism where a WTP boots up, discovers one or more ACs to create an association with. As part of the discovery process, the WTP identifies itself (vendor ID, hardware version, software version, etc.). One of the discovered ACs can then instruct the WTP to download a firmware image that the WTP should boot itself with at the end of the download process. Upon booting itself with this downloaded image, the WTP runs a protocol, quite possibly proprietary to the AC vendor, contained in the downloaded image to create an association with an AC and get configured to be a member of the WLAN. An AC from one vendor might download an image to a WTP that is completely different than an AC from another vendor. This does solve the end-user's requirement of getting interoperability between WTPs and ACs from different vendors. The control protocol used to get the WTP to become a member of the WLAN controlled and managed by the AC is totally upto the AC vendor's choice. Essentially, the solution becomes a simple protocol for the WTP to discover one or more ACs, identify itself to the ACs, and download an image from the AC, if possible, that it will boot itself with - a secure download problem rather than a WLAN configuration problem from an interoperability perspective. This solves the CAPWAP problem of interoperability without requiring a full-fledged, new control protocol that all the WTP and AC vendors have to implement for interoperability. It is sufficient to implement the simpler secure download protocol to get to interoperability. This removes the necessity to negotiate capabilities (split MAC vs local MAC, one person's split may not suit another but we cannot have infinite permutations of a split, etc.) since the WTP assumes capabilities that are contained in the image that the AC vendor chooses to build for it. Another benefit of this approach is the extensibility of this simpler approach to future wireless technologies or extensions to existing technologies since these are folded into the downloaded image and hence are transparent to the secure download protocol itself. What are the issues with such a secure download protocol? This requires an AC to have a bootable image for every single WTP that the AC wants to interoperate with. Which could be a matter of differentiation for the AC vendors. If one vendor supports 2 models of WTPs, while another one decides to support 10, then the marketplace could choose if they like the feature set of the former enough that they dont mind the reduced set of interoperable WTPs or whether they like the greater interoperability of the latter AC. Secondly, we need a mechanism for the WTP and the AC, soon after the discovery process, to create a trust relationship between each other so that the WTP is sure it is not downloading code from a malicious entity masquerading as an AC and the AC is sure it is not supplying code to an entity masquerading as a WTP. The secure download approach shifts the burden of interoperability to the AC vendors and lowers the barrier for the WTP vendors that strive for interoperability. This shift is fine since the AC is the center of control and management for a WLAN and it is in the AC vendor's interests to get to wider interoperability, if they so chose to do. This is also aligned with the current market reality where the AC vendors' capabilities determine what features are available on the WLAN. The WTP vendors are required to implement a simpler protocol to get to interoperability with multiple AC vendors. The level of interoperability is always determined by individual choices by the vendors. For example, an AC that only supports split MAC may not interoperate with a WTP that only suppports the local MAC. Arguably, the interoperability achievable by the secure download approach is no worse than what is possible with a full-blown control protocol. Not to mention the simplicity of the protocol that the CAPWAP WG needs to work on. We intend to submit a proposal along these lines to the CAPWAP WG. It will involve a simple process as follows: - a WTP discovers one or more ACs, - the WTP identifies itself to the ACs that it discovered, - the WTP and one of the ACs create a mutual trust relationship, and - the WTP downloading an image from an AC. The details will be present in the draft that will follow soon. This approach is quite different from what has been discussed in the WG so far. It probably also has implications on the objectives draft. I would like to initiate some discussion on whether all the mandatory objectives as stated in the current objectives draft are still valid. I understand that the objectives were stated with a full-fledged, open and/or externally verifiable protocol in mind. If a certain set of objectives precludes such a simpler solution then we may need to re-visit and discuss that set of objectives. In other words, if a set of objectives as they currently stand are unnecessary for solving the problem that we started out to address, then we should discuss these now. Thanks partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 13:33:06 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04966 for ; Wed, 9 Mar 2005 13:33:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AB28A204FF; Wed, 9 Mar 2005 13:33:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 926822043D; Wed, 9 Mar 2005 13:33:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 49C272043D for ; Wed, 9 Mar 2005 13:32:24 -0500 (EST) Received: from orsfmr005.jf.intel.com (fmr20.intel.com [134.134.136.19]) by mail.frascone.com (Postfix) with ESMTP id EC8F920430 for ; Wed, 9 Mar 2005 13:32:20 -0500 (EST) Received: from orsfmr100.jf.intel.com (orsfmr100.jf.intel.com [10.7.209.16]) by orsfmr005.jf.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j29IWE0h006577; Wed, 9 Mar 2005 18:32:14 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by orsfmr100.jf.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j29IWCpg032543; Wed, 9 Mar 2005 18:32:12 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005030910321220920 ; Wed, 09 Mar 2005 10:32:12 -0800 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Mar 2005 10:32:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: <2AF68A477DD44C4EBCBE338C24E7A9EE03BA61D8@orsmsx408> Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUkyTkZeOJkvi+lQLCb7JYxtzARZAAC4/Yw From: "Yang, Lily L" To: "Partha Narasimhan" , X-OriginalArrivalTime: 09 Mar 2005 18:32:12.0103 (UTC) FILETIME=[4F3E9570:01C524D6] X-Scanned-By: MIMEDefang 2.44 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 10:32:10 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Partha - Interoperability provides two aspects of benefits in my mind: Interoperability provides better choice for the customers because now they can choose different vendors for AC and WTP; interoperability also provides lower development cost for vendors because now they don't have to work with each individual vendor of the other end to make it work. While the former is the most visible benefit for the end users, the latter also offer economic incentives to the vendors that should not be overlooked.=20 While the simper approach you suggested can still provide the former, it does not at all address the latter, so I am hesitant to agree with your statement that "the interoperability achievable by the secure download approach is no worse than what is possible with a full-blown control protocol." Lily -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Partha Narasimhan Sent: Wednesday, March 09, 2005 8:59 AM To: capwap@frascone.com Subject: [Capwap] A simpler approach to CAPWAP The primary reason for the existence of the CAPWAP group is to solve an interoperability problem between ACs and WTPs from different vendors so that an end-user/customer has the choice of purchasing WTPs and ACs from different vendors. The existing marketplace is full of single-vendor solutions. To that extent, if an end-user is able to purchase a WTP from a vendor that is different than the vendor supplying the AC, but get them to interoperate with each other to create a functioning WLAN, then the end-user's objective is largely accomplished. Based on existing single-vendor WLAN solutions, it is obvious that the AC is where most of the control and management intelligence resides. It is not far from the truth to state the AC determines what functions are turned on at the WTPs and, hence, what features are available in the WLAN. Arguably, the interoperability problem can be restated as a customer's need to find WTPs that interoperate with his/her choice of AC. Or at a minimum, the WTPs need to follow and interoperate with the AC rather than the other way around.=20 Interoperability can be achieved at multiple levels. In most of the current discussion on the CAPWAP mailing list, the primary assumption seems to be that interoperability requirement seems to be between the individual software that both the WTP and the AC ship with and/or boot up with. Once both the devices are up and running with their images, the WTPs discover one or more ACs and, assuming everything is set up right, one of the discovered ACs will configure and bring up the WTP as part of the customer's WLAN using a protocol that will be defined as part of the CAPWAP WG's work. Interoperability can also be achieved using a simpler mechanism where a WTP boots up, discovers one or more ACs to create an association with. As part of the discovery process, the WTP identifies itself (vendor ID, hardware version, software version, etc.). One of the discovered ACs can then instruct the WTP to download a firmware image that the WTP should boot itself with at the end of the download process. Upon booting itself with this downloaded image, the WTP runs a protocol, quite possibly proprietary to the AC vendor, contained in the downloaded image to create an association with an AC and get configured to be a member of the WLAN. An AC from one vendor might download an image to a WTP that is completely different than an AC from another vendor. This does solve the end-user's requirement of getting interoperability between WTPs and ACs from different vendors. The control protocol used to get the WTP to become a member of the WLAN controlled and managed by the AC is totally upto the AC vendor's choice. Essentially, the solution becomes a simple protocol for the WTP to discover one or more ACs, identify itself to the ACs, and download an image from the AC, if possible, that it will boot itself with - a secure download problem rather than a WLAN configuration problem from an interoperability perspective. This solves the CAPWAP problem of interoperability without requiring a full-fledged, new control protocol that all the WTP and AC vendors have to implement for interoperability. It is sufficient to implement the simpler secure download protocol to get to interoperability. This removes the necessity to negotiate capabilities (split MAC vs local MAC, one person's split may not suit another but we cannot have infinite permutations of a split, etc.) since the WTP assumes capabilities that are contained in the image that the AC vendor chooses to build for it. Another benefit of this approach is the extensibility of this simpler approach to future wireless technologies or extensions to existing technologies since these are folded into the downloaded image and hence are transparent to the secure download protocol itself. What are the issues with such a secure download protocol? This requires an AC to have a bootable image for every single WTP that the AC wants to interoperate with. Which could be a matter of differentiation for the AC vendors. If one vendor supports 2 models of WTPs, while another one decides to support 10, then the marketplace could choose if they like the feature set of the former enough that they dont mind the reduced set of interoperable WTPs or whether they like the greater interoperability of the latter AC. Secondly, we need a mechanism for the WTP and the AC, soon after the discovery process, to create a trust relationship between each other so that the WTP is sure it is not downloading code from a malicious entity masquerading as an AC and the AC is sure it is not supplying code to an entity masquerading as a WTP.=20 The secure download approach shifts the burden of interoperability to the AC vendors and lowers the barrier for the WTP vendors that strive for interoperability. This shift is fine since the AC is the center of control and management for a WLAN and it is in the AC vendor's interests to get to wider interoperability, if they so chose to do. This is also aligned with the current market reality where the AC vendors' capabilities determine what features are available on the WLAN. The WTP vendors are required to implement a simpler protocol to get to interoperability with multiple AC vendors. The level of interoperability is always determined by individual choices by the vendors. For example, an AC that only supports split MAC may not interoperate with a WTP that only suppports the local MAC. Arguably, the interoperability achievable by the secure download approach is no worse than what is possible with a full-blown control protocol. Not to mention the simplicity of the protocol that the CAPWAP WG needs to work on. We intend to submit a proposal along these lines to the CAPWAP WG. It will involve a simple process as follows: - a WTP discovers one or more ACs, - the WTP identifies itself to the ACs that it discovered, - the WTP and one of the ACs create a mutual trust relationship, and - the WTP downloading an image from an AC. The details will be present in the draft that will follow soon. This approach is quite different from what has been discussed in the WG so far. It probably also has implications on the objectives draft. I would like to initiate some discussion on whether all the mandatory objectives as stated in the current objectives draft are still valid. I understand that the objectives were stated with a full-fledged, open and/or externally verifiable protocol in mind. If a certain set of objectives precludes such a simpler solution then we may need to re-visit and discuss that set of objectives. In other words, if a set of objectives as they currently stand are unnecessary for solving the problem that we started out to address, then we should discuss these now. Thanks partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 13:49:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06558 for ; Wed, 9 Mar 2005 13:49:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8E3752051E; Wed, 9 Mar 2005 13:49:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A0046204F1; Wed, 9 Mar 2005 13:49:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 546AA204F1 for ; Wed, 9 Mar 2005 13:48:02 -0500 (EST) Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by mail.frascone.com (Postfix) with SMTP id C717A204E1 for ; Wed, 9 Mar 2005 13:47:58 -0500 (EST) Received: from unknown (HELO MICHAELV-LT.yahoo.com) (mvakulenko@212.179.88.120 with login) by smtp015.mail.yahoo.com with SMTP; 9 Mar 2005 18:47:55 -0000 Message-Id: <6.2.1.2.0.20050309202605.045ee9b0@pop.mail.yahoo.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 To: "Partha Narasimhan" From: Michael Vakulenko Subject: Re: [Capwap] A simpler approach to CAPWAP Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 09 Mar 2005 20:45:25 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Partha, I don't see how your suggestion makes things simpler. If CAPWAP would follow your approach, this WG had to define standard APIs that needs to be supported by all interoperable WTPs. These APIs will have to be quite low-level and detailed to provide interface to 802.11 chipset, Ethernet driver and operating system of the WTPs. Moreover, different WTP models may use different processor cores and therefore firmware object code cannot be the same for all WTPs. (We are not talking about Java here, are we?.. :-) ) The real complexity of what you have proposed is in fact higher than traditional approach to protocol design, if you consider practicalities of achieving interoperability, stability and predictable performance for downloadable firmware. -- Michael V. http://www.WaveCompass.com At 06:58 PM 3/9/2005, Partha Narasimhan wrote: >The primary reason for the existence of the CAPWAP group is to solve >an interoperability problem between ACs and WTPs from different >vendors so that an end-user/customer has the choice of purchasing WTPs >and ACs from different vendors. The existing marketplace is full of >single-vendor solutions. To that extent, if an end-user is able to >purchase a WTP from a vendor that is different than the vendor >supplying the AC, but get them to interoperate with each other to >create a functioning WLAN, then the end-user's objective is largely >accomplished. > >Based on existing single-vendor WLAN solutions, it is obvious that the >AC is where most of the control and management intelligence >resides. It is not far from the truth to state the AC determines what >functions are turned on at the WTPs and, hence, what features are >available in the WLAN. Arguably, the interoperability problem can be >restated as a customer's need to find WTPs that interoperate with >his/her choice of AC. Or at a minimum, the WTPs need to follow and >interoperate with the AC rather than the other way around. > >Interoperability can be achieved at multiple levels. In most of the >current discussion on the CAPWAP mailing list, the primary assumption >seems to be that interoperability requirement seems to be between the >individual software that both the WTP and the AC ship with and/or boot >up with. Once both the devices are up and running with their images, >the WTPs discover one or more ACs and, assuming everything is set up >right, one of the discovered ACs will configure and bring up the WTP >as part of the customer's WLAN using a protocol that will be defined >as part of the CAPWAP WG's work. > >Interoperability can also be achieved using a simpler mechanism where >a WTP boots up, discovers one or more ACs to create an association >with. As part of the discovery process, the WTP identifies itself >(vendor ID, hardware version, software version, etc.). One of the >discovered ACs can then instruct the WTP to download a firmware image >that the WTP should boot itself with at the end of the download >process. Upon booting itself with this downloaded image, the WTP runs >a protocol, quite possibly proprietary to the AC vendor, contained in >the downloaded image to create an association with an AC and get >configured to be a member of the WLAN. An AC from one vendor might >download an image to a WTP that is completely different than an AC >from another vendor. This does solve the end-user's requirement of >getting interoperability between WTPs and ACs from different >vendors. The control protocol used to get the WTP to become a member >of the WLAN controlled and managed by the AC is totally upto the AC >vendor's choice. > >Essentially, the solution becomes a simple protocol for the WTP to >discover one or more ACs, identify itself to the ACs, and download an >image from the AC, if possible, that it will boot itself with - a >secure download problem rather than a WLAN configuration problem from >an interoperability perspective. This solves the CAPWAP problem of >interoperability without requiring a full-fledged, new control >protocol that all the WTP and AC vendors have to implement for >interoperability. It is sufficient to implement the simpler secure >download protocol to get to interoperability. This removes the >necessity to negotiate capabilities (split MAC vs local MAC, one >person's split may not suit another but we cannot have infinite >permutations of a split, etc.) since the WTP assumes capabilities that >are contained in the image that the AC vendor chooses to build for >it. Another benefit of this approach is the extensibility of this >simpler approach to future wireless technologies or extensions to >existing technologies since these are folded into the downloaded image >and hence are transparent to the secure download protocol itself. > >What are the issues with such a secure download protocol? This >requires an AC to have a bootable image for every single WTP that the >AC wants to interoperate with. Which could be a matter of >differentiation for the AC vendors. If one vendor supports 2 models of >WTPs, while another one decides to support 10, then the marketplace >could choose if they like the feature set of the former enough that >they dont mind the reduced set of interoperable WTPs or whether they >like the greater interoperability of the latter AC. Secondly, we need >a mechanism for the WTP and the AC, soon after the discovery process, >to create a trust relationship between each other so that the WTP is >sure it is not downloading code from a malicious entity masquerading >as an AC and the AC is sure it is not supplying code to an entity >masquerading as a WTP. > >The secure download approach shifts the burden of interoperability to >the AC vendors and lowers the barrier for the WTP vendors that strive >for interoperability. This shift is fine since the AC is the center of >control and management for a WLAN and it is in the AC vendor's >interests to get to wider interoperability, if they so chose to >do. This is also aligned with the current market reality where the AC >vendors' capabilities determine what features are available on the >WLAN. The WTP vendors are required to implement a simpler protocol to >get to interoperability with multiple AC vendors. The level of >interoperability is always determined by individual choices by the >vendors. For example, an AC that only supports split MAC may not >interoperate with a WTP that only suppports the local MAC. Arguably, >the interoperability achievable by the secure download approach is no >worse than what is possible with a full-blown control protocol. Not to >mention the simplicity of the protocol that the CAPWAP WG needs to >work on. > >We intend to submit a proposal along these lines to the CAPWAP WG. It >will involve a simple process as follows: >- a WTP discovers one or more ACs, >- the WTP identifies itself to the ACs that it discovered, >- the WTP and one of the ACs create a mutual trust relationship, and >- the WTP downloading an image from an AC. >The details will be present in the draft that will follow soon. > >This approach is quite different from what has been discussed in the >WG so far. It probably also has implications on the objectives >draft. I would like to initiate some discussion on whether all the >mandatory objectives as stated in the current objectives draft are >still valid. I understand that the objectives were stated with a >full-fledged, open and/or externally verifiable protocol in mind. If a >certain set of objectives precludes such a simpler solution then we >may need to re-visit and discuss that set of objectives. In other >words, if a set of objectives as they currently stand are unnecessary >for solving the problem that we started out to address, then we should >discuss these now. > >Thanks >partha >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap -- Michael Vakulenko Phone: +972-54-776-2269 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 13:56:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07440 for ; Wed, 9 Mar 2005 13:56:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6D9CE20555; Wed, 9 Mar 2005 13:56:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 47606204F6; Wed, 9 Mar 2005 13:56:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0261C204F6 for ; Wed, 9 Mar 2005 13:55:46 -0500 (EST) Received: from aruba-server.arubanetworks.com (216-31-249-252.cust.telepacific.net [216.31.249.252]) by mail.frascone.com (Postfix) with SMTP id 540AF204F1 for ; Wed, 9 Mar 2005 13:55:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: : Re: [Capwap] A simpler approach to CAPWAP Message-ID: Thread-Topic: : Re: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUk1LGwmO1RBi6iT7auwk6k3F21dAAAXtqT From: "Partha Narasimhan" To: "Inderpreet Singh" , "James Kempf" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 10:55:41 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable What we are proposing is not a 'desirable' firmware download option = inside a bigger control protocol. It is meant to restrict the control = protocol to a simple discover and download process.=20 The motivation for this is fairly simple. The primary question to answer = is whether the end-users require interoperability at - a software level, i.e. the original software running on each of the = WTP and the AC need to interoperate, or - a hardware level, i.e. buy cheaper (hopefully) WTPs from a different = vendor than the one supplying the AC, but get the AC to control and = manage the WTPs by downloading a new image into the WTPs, or - do they even care as long as the WLAN is up and running as advertised = by the AC vendor The AC in most networks controls what features show up on the deployed = WLAN. If a WTP from a different vendor shows up with a set of features = that the AC cannot exploit, then these features are simply not going to = be turned on. If the discover and download process solves the end-user's problems (the = same ones that we convince each other that we are solving), I dont = understand why there is no 'value' is such a solution. Especially, when = the problems are being solved with a simpler solution. This gives each = AC vendor all the more options to differentiate their products from the = competition.=20 Personally, I do not want to go down the path of specifying a = full-fledged control protocol simply because we have spent some time on = it or that this simpler approach is not seen as appealing to our = creative abilities. The important question to ask are whether this is = sufficient to solve the interoperability problems from an end-users' = perspective. Thanks partha -----Original Message----- From: Inderpreet Singh [mailto:isingh@chantrynetworks.com] Sent: Wed 3/9/2005 10:20 AM To: 'James Kempf'; Partha Narasimhan; capwap@frascone.com Cc:=09 Subject: RE: : Re: [Capwap] A simpler approach to CAPWAP James, I agree that firmware download is a nice to have. I am trying to rationalize the work that might potentially go on in defining yet = another method of firmware download in the context of CAPWAP. How is the = firmware download problem different and unique in the case of WTPs vs. routers, switches, printers, or any other networking device? Partha - I think what you are proposing is substantially changing the = scope of the CAPWAP charter. What you are proposing would mean that our group should be called PWAP WG as the control aspect would then be totally sidelined and that would be totally proprietary. I am not sure if there = is value in "only" a firmware update protocol for WTPs and ACs. --- Inderpreet Singh -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of James Kempf Sent: Wednesday, March 09, 2005 1:02 PM To: Partha Narasimhan; capwap@frascone.com Subject: **** SPAM **** 3.1: Re: [Capwap] A simpler approach to CAPWAP Partha, I believe having downloadable firmware is a highly desirable requirement = for CAPWAP, to ensure AC- WTP interoperability. However, I do not believe it is a replacement for having an interoperable protocol. From a managability standpoint, I'd = like to have a protocol that was standardized among AC vendors, not a bunch = of proprietary protocols that would all require different specialized management expertiese (which adds up to OPEX expense). Personally, I = don't think restricting CAPWAP goals just to downloadable firmware would = fufill the charter, but I'll let it up to the chairs to make the call. jak ----- Original Message -----=20 From: "Partha Narasimhan" To: Sent: Wednesday, March 09, 2005 8:58 AM Subject: [Capwap] A simpler approach to CAPWAP The primary reason for the existence of the CAPWAP group is to solve an interoperability problem between ACs and WTPs from different vendors so that an end-user/customer has the choice of purchasing WTPs and ACs from different vendors. The existing marketplace is full of single-vendor solutions. To that extent, if an end-user is able to purchase a WTP from a vendor that is different than the vendor supplying the AC, but get them to interoperate with each other to create a functioning WLAN, then the end-user's objective is largely accomplished. Based on existing single-vendor WLAN solutions, it is obvious that the AC is where most of the control and management intelligence resides. It is not far from the truth to state the AC determines what functions are turned on at the WTPs and, hence, what features are available in the WLAN. Arguably, the interoperability problem can be restated as a customer's need to find WTPs that interoperate with his/her choice of AC. Or at a minimum, the WTPs need to follow and interoperate with the AC rather than the other way around. Interoperability can be achieved at multiple levels. In most of the current discussion on the CAPWAP mailing list, the primary assumption seems to be that interoperability requirement seems to be between the individual software that both the WTP and the AC ship with and/or boot up with. Once both the devices are up and running with their images, the WTPs discover one or more ACs and, assuming everything is set up right, one of the discovered ACs will configure and bring up the WTP as part of the customer's WLAN using a protocol that will be defined as part of the CAPWAP WG's work. Interoperability can also be achieved using a simpler mechanism where a WTP boots up, discovers one or more ACs to create an association with. As part of the discovery process, the WTP identifies itself (vendor ID, hardware version, software version, etc.). One of the discovered ACs can then instruct the WTP to download a firmware image that the WTP should boot itself with at the end of the download process. Upon booting itself with this downloaded image, the WTP runs a protocol, quite possibly proprietary to the AC vendor, contained in the downloaded image to create an association with an AC and get configured to be a member of the WLAN. An AC from one vendor might download an image to a WTP that is completely different than an AC from another vendor. This does solve the end-user's requirement of getting interoperability between WTPs and ACs from different vendors. The control protocol used to get the WTP to become a member of the WLAN controlled and managed by the AC is totally upto the AC vendor's choice. Essentially, the solution becomes a simple protocol for the WTP to discover one or more ACs, identify itself to the ACs, and download an image from the AC, if possible, that it will boot itself with - a secure download problem rather than a WLAN configuration problem from an interoperability perspective. This solves the CAPWAP problem of interoperability without requiring a full-fledged, new control protocol that all the WTP and AC vendors have to implement for interoperability. It is sufficient to implement the simpler secure download protocol to get to interoperability. This removes the necessity to negotiate capabilities (split MAC vs local MAC, one person's split may not suit another but we cannot have infinite permutations of a split, etc.) since the WTP assumes capabilities that are contained in the image that the AC vendor chooses to build for it. Another benefit of this approach is the extensibility of this simpler approach to future wireless technologies or extensions to existing technologies since these are folded into the downloaded image and hence are transparent to the secure download protocol itself. What are the issues with such a secure download protocol? This requires an AC to have a bootable image for every single WTP that the AC wants to interoperate with. Which could be a matter of differentiation for the AC vendors. If one vendor supports 2 models of WTPs, while another one decides to support 10, then the marketplace could choose if they like the feature set of the former enough that they dont mind the reduced set of interoperable WTPs or whether they like the greater interoperability of the latter AC. Secondly, we need a mechanism for the WTP and the AC, soon after the discovery process, to create a trust relationship between each other so that the WTP is sure it is not downloading code from a malicious entity masquerading as an AC and the AC is sure it is not supplying code to an entity masquerading as a WTP. The secure download approach shifts the burden of interoperability to the AC vendors and lowers the barrier for the WTP vendors that strive for interoperability. This shift is fine since the AC is the center of control and management for a WLAN and it is in the AC vendor's interests to get to wider interoperability, if they so chose to do. This is also aligned with the current market reality where the AC vendors' capabilities determine what features are available on the WLAN. The WTP vendors are required to implement a simpler protocol to get to interoperability with multiple AC vendors. The level of interoperability is always determined by individual choices by the vendors. For example, an AC that only supports split MAC may not interoperate with a WTP that only suppports the local MAC. Arguably, the interoperability achievable by the secure download approach is no worse than what is possible with a full-blown control protocol. Not to mention the simplicity of the protocol that the CAPWAP WG needs to work on. We intend to submit a proposal along these lines to the CAPWAP WG. It will involve a simple process as follows: - a WTP discovers one or more ACs, - the WTP identifies itself to the ACs that it discovered, - the WTP and one of the ACs create a mutual trust relationship, and - the WTP downloading an image from an AC. The details will be present in the draft that will follow soon. This approach is quite different from what has been discussed in the WG so far. It probably also has implications on the objectives draft. I would like to initiate some discussion on whether all the mandatory objectives as stated in the current objectives draft are still valid. I understand that the objectives were stated with a full-fledged, open and/or externally verifiable protocol in mind. If a certain set of objectives precludes such a simpler solution then we may need to re-visit and discuss that set of objectives. In other words, if a set of objectives as they currently stand are unnecessary for solving the problem that we started out to address, then we should discuss these now. Thanks partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 14:03:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08227 for ; Wed, 9 Mar 2005 14:03:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A393D20577; Wed, 9 Mar 2005 14:03:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DAA40204FF; Wed, 9 Mar 2005 14:03:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DA877204FF for ; Wed, 9 Mar 2005 14:02:25 -0500 (EST) Received: from aruba-server.arubanetworks.com (216-31-249-252.cust.telepacific.net [216.31.249.252]) by mail.frascone.com (Postfix) with SMTP id A180F204F6 for ; Wed, 9 Mar 2005 14:02:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUkyTkZeOJkvi+lQLCb7JYxtzARZAAC4/YwAAE/m/M= From: "Partha Narasimhan" To: "Yang, Lily L" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 11:02:15 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Lily, Interoperability does not come for free. At a minimum, each vendor needs = to make a choice whether they want to make their boxes interoperate with = other vendors' boxes. It is not sufficient to define a control protocol = and expect interoperability if the individual vendors choose not to = implement the protocol at their end. This will be important especially = in the case where the WTP vendors do not want to be burdened with the = implementation of a complex protocol in order to claim interoperability. = If none of the WTP vendors choose to implement this control protocol = because it is seen as too much work (not to mention participation in = interoperability plugfests and certification programs), then the CAPWAP = group would have failed and we would have no interoperability. This = approach moves the burden of interopreability to one side (the AC = vendors) and requires the WTP vendors to implement a much simpler = protocol. Thanks partha -----Original Message----- From: Yang, Lily L [mailto:lily.l.yang@intel.com] Sent: Wed 3/9/2005 10:32 AM To: Partha Narasimhan; capwap@frascone.com Cc:=09 Subject: RE: [Capwap] A simpler approach to CAPWAP Partha - Interoperability provides two aspects of benefits in my mind: Interoperability provides better choice for the customers because now they can choose different vendors for AC and WTP; interoperability also provides lower development cost for vendors because now they don't have to work with each individual vendor of the other end to make it work. While the former is the most visible benefit for the end users, the latter also offer economic incentives to the vendors that should not be overlooked.=20 While the simper approach you suggested can still provide the former, it does not at all address the latter, so I am hesitant to agree with your statement that "the interoperability achievable by the secure download approach is no worse than what is possible with a full-blown control protocol." Lily -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Partha Narasimhan Sent: Wednesday, March 09, 2005 8:59 AM To: capwap@frascone.com Subject: [Capwap] A simpler approach to CAPWAP The primary reason for the existence of the CAPWAP group is to solve an interoperability problem between ACs and WTPs from different vendors so that an end-user/customer has the choice of purchasing WTPs and ACs from different vendors. The existing marketplace is full of single-vendor solutions. To that extent, if an end-user is able to purchase a WTP from a vendor that is different than the vendor supplying the AC, but get them to interoperate with each other to create a functioning WLAN, then the end-user's objective is largely accomplished. Based on existing single-vendor WLAN solutions, it is obvious that the AC is where most of the control and management intelligence resides. It is not far from the truth to state the AC determines what functions are turned on at the WTPs and, hence, what features are available in the WLAN. Arguably, the interoperability problem can be restated as a customer's need to find WTPs that interoperate with his/her choice of AC. Or at a minimum, the WTPs need to follow and interoperate with the AC rather than the other way around.=20 Interoperability can be achieved at multiple levels. In most of the current discussion on the CAPWAP mailing list, the primary assumption seems to be that interoperability requirement seems to be between the individual software that both the WTP and the AC ship with and/or boot up with. Once both the devices are up and running with their images, the WTPs discover one or more ACs and, assuming everything is set up right, one of the discovered ACs will configure and bring up the WTP as part of the customer's WLAN using a protocol that will be defined as part of the CAPWAP WG's work. Interoperability can also be achieved using a simpler mechanism where a WTP boots up, discovers one or more ACs to create an association with. As part of the discovery process, the WTP identifies itself (vendor ID, hardware version, software version, etc.). One of the discovered ACs can then instruct the WTP to download a firmware image that the WTP should boot itself with at the end of the download process. Upon booting itself with this downloaded image, the WTP runs a protocol, quite possibly proprietary to the AC vendor, contained in the downloaded image to create an association with an AC and get configured to be a member of the WLAN. An AC from one vendor might download an image to a WTP that is completely different than an AC from another vendor. This does solve the end-user's requirement of getting interoperability between WTPs and ACs from different vendors. The control protocol used to get the WTP to become a member of the WLAN controlled and managed by the AC is totally upto the AC vendor's choice. Essentially, the solution becomes a simple protocol for the WTP to discover one or more ACs, identify itself to the ACs, and download an image from the AC, if possible, that it will boot itself with - a secure download problem rather than a WLAN configuration problem from an interoperability perspective. This solves the CAPWAP problem of interoperability without requiring a full-fledged, new control protocol that all the WTP and AC vendors have to implement for interoperability. It is sufficient to implement the simpler secure download protocol to get to interoperability. This removes the necessity to negotiate capabilities (split MAC vs local MAC, one person's split may not suit another but we cannot have infinite permutations of a split, etc.) since the WTP assumes capabilities that are contained in the image that the AC vendor chooses to build for it. Another benefit of this approach is the extensibility of this simpler approach to future wireless technologies or extensions to existing technologies since these are folded into the downloaded image and hence are transparent to the secure download protocol itself. What are the issues with such a secure download protocol? This requires an AC to have a bootable image for every single WTP that the AC wants to interoperate with. Which could be a matter of differentiation for the AC vendors. If one vendor supports 2 models of WTPs, while another one decides to support 10, then the marketplace could choose if they like the feature set of the former enough that they dont mind the reduced set of interoperable WTPs or whether they like the greater interoperability of the latter AC. Secondly, we need a mechanism for the WTP and the AC, soon after the discovery process, to create a trust relationship between each other so that the WTP is sure it is not downloading code from a malicious entity masquerading as an AC and the AC is sure it is not supplying code to an entity masquerading as a WTP.=20 The secure download approach shifts the burden of interoperability to the AC vendors and lowers the barrier for the WTP vendors that strive for interoperability. This shift is fine since the AC is the center of control and management for a WLAN and it is in the AC vendor's interests to get to wider interoperability, if they so chose to do. This is also aligned with the current market reality where the AC vendors' capabilities determine what features are available on the WLAN. The WTP vendors are required to implement a simpler protocol to get to interoperability with multiple AC vendors. The level of interoperability is always determined by individual choices by the vendors. For example, an AC that only supports split MAC may not interoperate with a WTP that only suppports the local MAC. Arguably, the interoperability achievable by the secure download approach is no worse than what is possible with a full-blown control protocol. Not to mention the simplicity of the protocol that the CAPWAP WG needs to work on. We intend to submit a proposal along these lines to the CAPWAP WG. It will involve a simple process as follows: - a WTP discovers one or more ACs, - the WTP identifies itself to the ACs that it discovered, - the WTP and one of the ACs create a mutual trust relationship, and - the WTP downloading an image from an AC. The details will be present in the draft that will follow soon. This approach is quite different from what has been discussed in the WG so far. It probably also has implications on the objectives draft. I would like to initiate some discussion on whether all the mandatory objectives as stated in the current objectives draft are still valid. I understand that the objectives were stated with a full-fledged, open and/or externally verifiable protocol in mind. If a certain set of objectives precludes such a simpler solution then we may need to re-visit and discuss that set of objectives. In other words, if a set of objectives as they currently stand are unnecessary for solving the problem that we started out to address, then we should discuss these now. Thanks partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 14:07:14 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08512 for ; Wed, 9 Mar 2005 14:07:10 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9514F20587; Wed, 9 Mar 2005 14:07:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9F79A2052A; Wed, 9 Mar 2005 14:07:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 791E52052A for ; Wed, 9 Mar 2005 14:06:27 -0500 (EST) Received: from aruba-server.arubanetworks.com (216-31-249-253.cust.telepacific.net [216.31.249.253]) by mail.frascone.com (Postfix) with SMTP id 8675C204F6 for ; Wed, 9 Mar 2005 14:06:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUk2IMNjzsHax5SRGmEHC4WPKXTBAAAgp6Y From: "Partha Narasimhan" To: "Michael Vakulenko" Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 11:06:18 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Just to clarify.... This moves the onus of interoperability onto the AC vendors. They make = images for a set of WTPs that they want to interoperate with. The WTP = vendors just have to implement a protocol where they discover ACs, = identify themselves, and have the ability to download an image and boot = themselves with it. The original image on WTP could do other things (the = WTP vendor's choice) with their installed images in an environment where = they are unable to discover an AC.=20 We are not calling for specifying how a WTP is built or with what = components. Once it is built, every AC vendor that wants that particular = model of WTP to work with needs to work with that WTP vendor and create = their own version of a downloadable image for that board.=20 Thanks partha -----Original Message----- From: Michael Vakulenko [mailto:michaelv@wavecompass.com] Sent: Wed 3/9/2005 10:45 AM To: Partha Narasimhan Cc: capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP Partha, I don't see how your suggestion makes things simpler. If CAPWAP would=20 follow your approach, this WG had to define standard APIs that needs to = be=20 supported by all interoperable WTPs. These APIs will have to be quite=20 low-level and detailed to provide interface to 802.11 chipset, Ethernet=20 driver and operating system of the WTPs. Moreover, different WTP models may use different processor cores and=20 therefore firmware object code cannot be the same for all WTPs. (We are = not=20 talking about Java here, are we?.. :-) ) The real complexity of what you have proposed is in fact higher than=20 traditional approach to protocol design, if you consider practicalities = of=20 achieving interoperability, stability and predictable performance for=20 downloadable firmware. -- Michael V. http://www.WaveCompass.com At 06:58 PM 3/9/2005, Partha Narasimhan wrote: >The primary reason for the existence of the CAPWAP group is to solve >an interoperability problem between ACs and WTPs from different >vendors so that an end-user/customer has the choice of purchasing WTPs >and ACs from different vendors. The existing marketplace is full of >single-vendor solutions. To that extent, if an end-user is able to >purchase a WTP from a vendor that is different than the vendor >supplying the AC, but get them to interoperate with each other to >create a functioning WLAN, then the end-user's objective is largely >accomplished. > >Based on existing single-vendor WLAN solutions, it is obvious that the >AC is where most of the control and management intelligence >resides. It is not far from the truth to state the AC determines what >functions are turned on at the WTPs and, hence, what features are >available in the WLAN. Arguably, the interoperability problem can be >restated as a customer's need to find WTPs that interoperate with >his/her choice of AC. Or at a minimum, the WTPs need to follow and >interoperate with the AC rather than the other way around. > >Interoperability can be achieved at multiple levels. In most of the >current discussion on the CAPWAP mailing list, the primary assumption >seems to be that interoperability requirement seems to be between the >individual software that both the WTP and the AC ship with and/or boot >up with. Once both the devices are up and running with their images, >the WTPs discover one or more ACs and, assuming everything is set up >right, one of the discovered ACs will configure and bring up the WTP >as part of the customer's WLAN using a protocol that will be defined >as part of the CAPWAP WG's work. > >Interoperability can also be achieved using a simpler mechanism where >a WTP boots up, discovers one or more ACs to create an association >with. As part of the discovery process, the WTP identifies itself >(vendor ID, hardware version, software version, etc.). One of the >discovered ACs can then instruct the WTP to download a firmware image >that the WTP should boot itself with at the end of the download >process. Upon booting itself with this downloaded image, the WTP runs >a protocol, quite possibly proprietary to the AC vendor, contained in >the downloaded image to create an association with an AC and get >configured to be a member of the WLAN. An AC from one vendor might >download an image to a WTP that is completely different than an AC >from another vendor. This does solve the end-user's requirement of >getting interoperability between WTPs and ACs from different >vendors. The control protocol used to get the WTP to become a member >of the WLAN controlled and managed by the AC is totally upto the AC >vendor's choice. > >Essentially, the solution becomes a simple protocol for the WTP to >discover one or more ACs, identify itself to the ACs, and download an >image from the AC, if possible, that it will boot itself with - a >secure download problem rather than a WLAN configuration problem from >an interoperability perspective. This solves the CAPWAP problem of >interoperability without requiring a full-fledged, new control >protocol that all the WTP and AC vendors have to implement for >interoperability. It is sufficient to implement the simpler secure >download protocol to get to interoperability. This removes the >necessity to negotiate capabilities (split MAC vs local MAC, one >person's split may not suit another but we cannot have infinite >permutations of a split, etc.) since the WTP assumes capabilities that >are contained in the image that the AC vendor chooses to build for >it. Another benefit of this approach is the extensibility of this >simpler approach to future wireless technologies or extensions to >existing technologies since these are folded into the downloaded image >and hence are transparent to the secure download protocol itself. > >What are the issues with such a secure download protocol? This >requires an AC to have a bootable image for every single WTP that the >AC wants to interoperate with. Which could be a matter of >differentiation for the AC vendors. If one vendor supports 2 models of >WTPs, while another one decides to support 10, then the marketplace >could choose if they like the feature set of the former enough that >they dont mind the reduced set of interoperable WTPs or whether they >like the greater interoperability of the latter AC. Secondly, we need >a mechanism for the WTP and the AC, soon after the discovery process, >to create a trust relationship between each other so that the WTP is >sure it is not downloading code from a malicious entity masquerading >as an AC and the AC is sure it is not supplying code to an entity >masquerading as a WTP. > >The secure download approach shifts the burden of interoperability to >the AC vendors and lowers the barrier for the WTP vendors that strive >for interoperability. This shift is fine since the AC is the center of >control and management for a WLAN and it is in the AC vendor's >interests to get to wider interoperability, if they so chose to >do. This is also aligned with the current market reality where the AC >vendors' capabilities determine what features are available on the >WLAN. The WTP vendors are required to implement a simpler protocol to >get to interoperability with multiple AC vendors. The level of >interoperability is always determined by individual choices by the >vendors. For example, an AC that only supports split MAC may not >interoperate with a WTP that only suppports the local MAC. Arguably, >the interoperability achievable by the secure download approach is no >worse than what is possible with a full-blown control protocol. Not to >mention the simplicity of the protocol that the CAPWAP WG needs to >work on. > >We intend to submit a proposal along these lines to the CAPWAP WG. It >will involve a simple process as follows: >- a WTP discovers one or more ACs, >- the WTP identifies itself to the ACs that it discovered, >- the WTP and one of the ACs create a mutual trust relationship, and >- the WTP downloading an image from an AC. >The details will be present in the draft that will follow soon. > >This approach is quite different from what has been discussed in the >WG so far. It probably also has implications on the objectives >draft. I would like to initiate some discussion on whether all the >mandatory objectives as stated in the current objectives draft are >still valid. I understand that the objectives were stated with a >full-fledged, open and/or externally verifiable protocol in mind. If a >certain set of objectives precludes such a simpler solution then we >may need to re-visit and discuss that set of objectives. In other >words, if a set of objectives as they currently stand are unnecessary >for solving the problem that we started out to address, then we should >discuss these now. > >Thanks >partha >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap -- Michael Vakulenko Phone: +972-54-776-2269 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 14:15:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09104 for ; Wed, 9 Mar 2005 14:15:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AF180205B8; Wed, 9 Mar 2005 14:15:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2580C20587; Wed, 9 Mar 2005 14:15:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF9B220558 for ; Wed, 9 Mar 2005 14:14:37 -0500 (EST) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 30C9720555 for ; Wed, 9 Mar 2005 14:14:33 -0500 (EST) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j29JCHwh096319; Wed, 9 Mar 2005 11:12:17 -0800 (PST) (envelope-from dharkins@trpz.com) Message-Id: <200503091912.j29JCHwh096319@homebrew.trpz.com> To: Michael Vakulenko Cc: "Partha Narasimhan" , capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP In-Reply-To: Your message of "Wed, 09 Mar 2005 20:45:25 +0200." <6.2.1.2.0.20050309202605.045ee9b0@pop.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <96317.1110395537.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 09 Mar 2005 11:12:17 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On the contrary. If the CAPWAP protocol defines a full control plane and data frame encapsulation it will have to define standard APIs that need to be supported by all interoperable WTPs. If Partha's approach is taken then all that is defined is a discovery and download protocol. The WTC runs the downloaded image and that contains the (not-defined by CAPWAP) control and data frame protocols. No we're not talking about Java. The practicalities of achieving interoperability are solely on implementation of the discovery and download protocol. It is simple and therefore acheiving interoperability would not be hard. The practicalities of achieving stability and predictable performance are borne by the AC vendors who will guarantee that the image they provide to a WTP is stable and has predictable performance. Dan. On Wed, 09 Mar 2005 20:45:25 +0200 you wrote > Partha, > > I don't see how your suggestion makes things simpler. If CAPWAP would > follow your approach, this WG had to define standard APIs that needs to be > supported by all interoperable WTPs. These APIs will have to be quite > low-level and detailed to provide interface to 802.11 chipset, Ethernet > driver and operating system of the WTPs. > > Moreover, different WTP models may use different processor cores and > therefore firmware object code cannot be the same for all WTPs. (We are not > talking about Java here, are we?.. :-) ) > > The real complexity of what you have proposed is in fact higher than > traditional approach to protocol design, if you consider practicalities of > achieving interoperability, stability and predictable performance for > downloadable firmware. > > -- Michael V. > http://www.WaveCompass.com > > > At 06:58 PM 3/9/2005, Partha Narasimhan wrote: > > >The primary reason for the existence of the CAPWAP group is to solve > >an interoperability problem between ACs and WTPs from different > >vendors so that an end-user/customer has the choice of purchasing WTPs > >and ACs from different vendors. The existing marketplace is full of > >single-vendor solutions. To that extent, if an end-user is able to > >purchase a WTP from a vendor that is different than the vendor > >supplying the AC, but get them to interoperate with each other to > >create a functioning WLAN, then the end-user's objective is largely > >accomplished. > > > >Based on existing single-vendor WLAN solutions, it is obvious that the > >AC is where most of the control and management intelligence > >resides. It is not far from the truth to state the AC determines what > >functions are turned on at the WTPs and, hence, what features are > >available in the WLAN. Arguably, the interoperability problem can be > >restated as a customer's need to find WTPs that interoperate with > >his/her choice of AC. Or at a minimum, the WTPs need to follow and > >interoperate with the AC rather than the other way around. > > > >Interoperability can be achieved at multiple levels. In most of the > >current discussion on the CAPWAP mailing list, the primary assumption > >seems to be that interoperability requirement seems to be between the > >individual software that both the WTP and the AC ship with and/or boot > >up with. Once both the devices are up and running with their images, > >the WTPs discover one or more ACs and, assuming everything is set up > >right, one of the discovered ACs will configure and bring up the WTP > >as part of the customer's WLAN using a protocol that will be defined > >as part of the CAPWAP WG's work. > > > >Interoperability can also be achieved using a simpler mechanism where > >a WTP boots up, discovers one or more ACs to create an association > >with. As part of the discovery process, the WTP identifies itself > >(vendor ID, hardware version, software version, etc.). One of the > >discovered ACs can then instruct the WTP to download a firmware image > >that the WTP should boot itself with at the end of the download > >process. Upon booting itself with this downloaded image, the WTP runs > >a protocol, quite possibly proprietary to the AC vendor, contained in > >the downloaded image to create an association with an AC and get > >configured to be a member of the WLAN. An AC from one vendor might > >download an image to a WTP that is completely different than an AC > >from another vendor. This does solve the end-user's requirement of > >getting interoperability between WTPs and ACs from different > >vendors. The control protocol used to get the WTP to become a member > >of the WLAN controlled and managed by the AC is totally upto the AC > >vendor's choice. > > > >Essentially, the solution becomes a simple protocol for the WTP to > >discover one or more ACs, identify itself to the ACs, and download an > >image from the AC, if possible, that it will boot itself with - a > >secure download problem rather than a WLAN configuration problem from > >an interoperability perspective. This solves the CAPWAP problem of > >interoperability without requiring a full-fledged, new control > >protocol that all the WTP and AC vendors have to implement for > >interoperability. It is sufficient to implement the simpler secure > >download protocol to get to interoperability. This removes the > >necessity to negotiate capabilities (split MAC vs local MAC, one > >person's split may not suit another but we cannot have infinite > >permutations of a split, etc.) since the WTP assumes capabilities that > >are contained in the image that the AC vendor chooses to build for > >it. Another benefit of this approach is the extensibility of this > >simpler approach to future wireless technologies or extensions to > >existing technologies since these are folded into the downloaded image > >and hence are transparent to the secure download protocol itself. > > > >What are the issues with such a secure download protocol? This > >requires an AC to have a bootable image for every single WTP that the > >AC wants to interoperate with. Which could be a matter of > >differentiation for the AC vendors. If one vendor supports 2 models of > >WTPs, while another one decides to support 10, then the marketplace > >could choose if they like the feature set of the former enough that > >they dont mind the reduced set of interoperable WTPs or whether they > >like the greater interoperability of the latter AC. Secondly, we need > >a mechanism for the WTP and the AC, soon after the discovery process, > >to create a trust relationship between each other so that the WTP is > >sure it is not downloading code from a malicious entity masquerading > >as an AC and the AC is sure it is not supplying code to an entity > >masquerading as a WTP. > > > >The secure download approach shifts the burden of interoperability to > >the AC vendors and lowers the barrier for the WTP vendors that strive > >for interoperability. This shift is fine since the AC is the center of > >control and management for a WLAN and it is in the AC vendor's > >interests to get to wider interoperability, if they so chose to > >do. This is also aligned with the current market reality where the AC > >vendors' capabilities determine what features are available on the > >WLAN. The WTP vendors are required to implement a simpler protocol to > >get to interoperability with multiple AC vendors. The level of > >interoperability is always determined by individual choices by the > >vendors. For example, an AC that only supports split MAC may not > >interoperate with a WTP that only suppports the local MAC. Arguably, > >the interoperability achievable by the secure download approach is no > >worse than what is possible with a full-blown control protocol. Not to > >mention the simplicity of the protocol that the CAPWAP WG needs to > >work on. > > > >We intend to submit a proposal along these lines to the CAPWAP WG. It > >will involve a simple process as follows: > >- a WTP discovers one or more ACs, > >- the WTP identifies itself to the ACs that it discovered, > >- the WTP and one of the ACs create a mutual trust relationship, and > >- the WTP downloading an image from an AC. > >The details will be present in the draft that will follow soon. > > > >This approach is quite different from what has been discussed in the > >WG so far. It probably also has implications on the objectives > >draft. I would like to initiate some discussion on whether all the > >mandatory objectives as stated in the current objectives draft are > >still valid. I understand that the objectives were stated with a > >full-fledged, open and/or externally verifiable protocol in mind. If a > >certain set of objectives precludes such a simpler solution then we > >may need to re-visit and discuss that set of objectives. In other > >words, if a set of objectives as they currently stand are unnecessary > >for solving the problem that we started out to address, then we should > >discuss these now. > > > >Thanks > >partha > >_______________________________________________ > >Capwap mailing list > >Capwap@frascone.com > >http://mail.frascone.com/mailman/listinfo/capwap > > -- Michael Vakulenko > Phone: +972-54-776-2269 > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 14:15:27 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09164 for ; Wed, 9 Mar 2005 14:15:27 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7230A205EA; Wed, 9 Mar 2005 14:15:24 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DCF12205DA; Wed, 9 Mar 2005 14:15:13 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3CEF120558 for ; Wed, 9 Mar 2005 14:14:46 -0500 (EST) Received: from WNIMAIL.WoodsideNet.Com (wnifwl.woodsidenet.com [65.192.186.2]) by mail.frascone.com (Postfix) with ESMTP id 4B44E20555 for ; Wed, 9 Mar 2005 14:14:43 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: <3FFBC907DD03A34CA4410C5C745DEB1205C4DEB8@wnimail.WoodsideNet.Com> Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUk2IMNjzsHax5SRGmEHC4WPKXTBAAAgp6YAAAvO5A= From: "Paul Lambert" To: "Partha Narasimhan" , "Michael Vakulenko" Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 11:14:39 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable This 'simpler' approach would never work as propoposed to=20 replace other control functioanlity. A software upgrade mechanism might be desireable. This upgrade process would never replace a fuller set of control protocols. > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Partha Narasimhan > Sent: Wednesday, March 09, 2005 11:06 AM > To: Michael Vakulenko > Cc: capwap@frascone.com > Subject: RE: [Capwap] A simpler approach to CAPWAP >=20 > Just to clarify.... >=20 > This moves the onus of interoperability onto the AC vendors.=20 > They make images for a set of WTPs that they want to=20 > interoperate with.=20 The AC vendor may not have the desire or the bandwidth to make WTP images. Unless the WTP are on standardized hardwar, how would a AC vendor build an image?=20 >The WTP vendors just have to implement a=20 > protocol where they discover ACs, identify themselves, and=20 > have the ability to download an image and boot themselves=20 > with it. The original image on WTP could do other things (the=20 > WTP vendor's choice) with their installed images in an=20 > environment where they are unable to discover an AC.=20 >=20 > We are not calling for specifying how a WTP is built or with=20 > what components. Once it is built, every AC vendor that wants=20 > that particular model of WTP to work with needs to work with=20 > that WTP vendor and create their own version of a=20 > downloadable image for that board.=20 This is NOT the nature of open interoperable standards. A=20 Company should not have to work directly with every other vendor to create interoperable systems. Paul _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 14:26:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09991 for ; Wed, 9 Mar 2005 14:26:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A03C6205CE; Wed, 9 Mar 2005 14:26:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 07DDA20577; Wed, 9 Mar 2005 14:26:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 62E6420593 for ; Wed, 9 Mar 2005 14:25:12 -0500 (EST) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 8867420577 for ; Wed, 9 Mar 2005 14:25:10 -0500 (EST) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j29JMrY1096382; Wed, 9 Mar 2005 11:22:53 -0800 (PST) (envelope-from dharkins@trpz.com) Message-Id: <200503091922.j29JMrY1096382@homebrew.trpz.com> To: "Paul Lambert" Cc: "Partha Narasimhan" , "Michael Vakulenko" , capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP In-Reply-To: Your message of "Wed, 09 Mar 2005 11:14:39 PST." <3FFBC907DD03A34CA4410C5C745DEB1205C4DEB8@wnimail.WoodsideNet.Com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <96380.1110396173.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 09 Mar 2005 11:22:53 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Paul, I don't think it's designed to replace other control functionality. The point is that it is not necessary to standardize that control functionality. The control functionality (and how and where to split a MAC, for instance) is all contained in the code running on the AC and the code in the image the AC provides to the WTP. How the control plane and data encapsulation are defined is up to the AC vendor (who wrote the code for running on the AC and also the code in the image provided to the WTC) and not to the IETF. Let a Hundred Flowers Bloom! Dan. On Wed, 09 Mar 2005 11:14:39 PST you wrote > > This 'simpler' approach would never work as propoposed to > replace other control functioanlity. > > A software upgrade mechanism might be desireable. This > upgrade process would never replace a fuller set of control protocols. > > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Partha Narasimhan > > Sent: Wednesday, March 09, 2005 11:06 AM > > To: Michael Vakulenko > > Cc: capwap@frascone.com > > Subject: RE: [Capwap] A simpler approach to CAPWAP > > > > Just to clarify.... > > > > This moves the onus of interoperability onto the AC vendors. > > They make images for a set of WTPs that they want to > > interoperate with. > > The AC vendor may not have the desire or the bandwidth to make WTP > images. > > Unless the WTP are on standardized hardwar, how would a AC vendor build > an image? > > >The WTP vendors just have to implement a > > protocol where they discover ACs, identify themselves, and > > have the ability to download an image and boot themselves > > with it. The original image on WTP could do other things (the > > WTP vendor's choice) with their installed images in an > > environment where they are unable to discover an AC. > > > > We are not calling for specifying how a WTP is built or with > > what components. Once it is built, every AC vendor that wants > > that particular model of WTP to work with needs to work with > > that WTP vendor and create their own version of a > > downloadable image for that board. > > This is NOT the nature of open interoperable standards. A > Company should not have to work directly with every other vendor > to create interoperable systems. > > Paul > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 14:28:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10273 for ; Wed, 9 Mar 2005 14:28:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 894A7205EB; Wed, 9 Mar 2005 14:28:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8794C20593; Wed, 9 Mar 2005 14:28:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CFA4C20593 for ; Wed, 9 Mar 2005 14:27:38 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mail.frascone.com (Postfix) with ESMTP id 614BC20577 for ; Wed, 9 Mar 2005 14:27:35 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 68so496838wra for ; Wed, 09 Mar 2005 11:27:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=YHt1SwYS0/0bs5Kj3h8K30FBRlwvOG/1CwVgM9+YCEZV8o38nANrbbTNMy8UXVB+ULK+8oHc4g8gZgLHIQ9Bj2Xy1FmvxZR2MSDF9T6O4RL93+kBxVmRoCaYV1xVdz7xkjahBWuT+FgPPV0fOLUaToABVc+F0DmKa5c6XzXtIAU= Received: by 10.54.45.14 with SMTP id s14mr1053924wrs; Wed, 09 Mar 2005 11:27:32 -0800 (PST) Received: by 10.54.49.27 with HTTP; Wed, 9 Mar 2005 11:27:29 -0800 (PST) Message-ID: From: Inderpreet Singh Reply-To: Inderpreet Singh To: capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP In-Reply-To: <01ce01c524d2$1ac705b0$456015ac@dcml.docomolabsusa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <01ce01c524d2$1ac705b0$456015ac@dcml.docomolabsusa.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 14:27:29 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit James, I agree that firmware download is a nice to have. I am trying to rationalize the work that might potentially go on in defining yet another method of firmware download in the context of CAPWAP. How is the firmware download problem different and unique in the case of WTPs vs. routers, switches, printers, or any other networking device? Partha - I think what you are proposing is substantially changing the scope of the CAPWAP charter. What you are proposing would mean that our group should be called PWAP WG as the control aspect would then be totally sidelined and that would be totally proprietary. I am not sure if there is value in "only" a firmware update protocol for WTPs and ACs. --- Inderpreet Singh On Wed, 9 Mar 2005 10:01:57 -0800, James Kempf wrote: > Partha, > > I believe having downloadable firmware is a highly desirable requirement for > CAPWAP, to ensure AC- > WTP interoperability. However, I do not believe it is a replacement for > having an interoperable protocol. From a managability standpoint, I'd like > to have a protocol that was standardized among AC vendors, not a bunch of > proprietary protocols that would all require different specialized > management expertiese (which adds up to OPEX expense). Personally, I don't > think restricting CAPWAP goals just to downloadable firmware would fufill > the charter, but I'll let it up to the chairs to make the call. > > jak > > > ----- Original Message ----- > From: "Partha Narasimhan" > To: > Sent: Wednesday, March 09, 2005 8:58 AM > Subject: [Capwap] A simpler approach to CAPWAP > > The primary reason for the existence of the CAPWAP group is to solve > an interoperability problem between ACs and WTPs from different > vendors so that an end-user/customer has the choice of purchasing WTPs > and ACs from different vendors. The existing marketplace is full of > single-vendor solutions. To that extent, if an end-user is able to > purchase a WTP from a vendor that is different than the vendor > supplying the AC, but get them to interoperate with each other to > create a functioning WLAN, then the end-user's objective is largely > accomplished. > > Based on existing single-vendor WLAN solutions, it is obvious that the > AC is where most of the control and management intelligence > resides. It is not far from the truth to state the AC determines what > functions are turned on at the WTPs and, hence, what features are > available in the WLAN. Arguably, the interoperability problem can be > restated as a customer's need to find WTPs that interoperate with > his/her choice of AC. Or at a minimum, the WTPs need to follow and > interoperate with the AC rather than the other way around. > > Interoperability can be achieved at multiple levels. In most of the > current discussion on the CAPWAP mailing list, the primary assumption > seems to be that interoperability requirement seems to be between the > individual software that both the WTP and the AC ship with and/or boot > up with. Once both the devices are up and running with their images, > the WTPs discover one or more ACs and, assuming everything is set up > right, one of the discovered ACs will configure and bring up the WTP > as part of the customer's WLAN using a protocol that will be defined > as part of the CAPWAP WG's work. > > Interoperability can also be achieved using a simpler mechanism where > a WTP boots up, discovers one or more ACs to create an association > with. As part of the discovery process, the WTP identifies itself > (vendor ID, hardware version, software version, etc.). One of the > discovered ACs can then instruct the WTP to download a firmware image > that the WTP should boot itself with at the end of the download > process. Upon booting itself with this downloaded image, the WTP runs > a protocol, quite possibly proprietary to the AC vendor, contained in > the downloaded image to create an association with an AC and get > configured to be a member of the WLAN. An AC from one vendor might > download an image to a WTP that is completely different than an AC > from another vendor. This does solve the end-user's requirement of > getting interoperability between WTPs and ACs from different > vendors. The control protocol used to get the WTP to become a member > of the WLAN controlled and managed by the AC is totally upto the AC > vendor's choice. > > Essentially, the solution becomes a simple protocol for the WTP to > discover one or more ACs, identify itself to the ACs, and download an > image from the AC, if possible, that it will boot itself with - a > secure download problem rather than a WLAN configuration problem from > an interoperability perspective. This solves the CAPWAP problem of > interoperability without requiring a full-fledged, new control > protocol that all the WTP and AC vendors have to implement for > interoperability. It is sufficient to implement the simpler secure > download protocol to get to interoperability. This removes the > necessity to negotiate capabilities (split MAC vs local MAC, one > person's split may not suit another but we cannot have infinite > permutations of a split, etc.) since the WTP assumes capabilities that > are contained in the image that the AC vendor chooses to build for > it. Another benefit of this approach is the extensibility of this > simpler approach to future wireless technologies or extensions to > existing technologies since these are folded into the downloaded image > and hence are transparent to the secure download protocol itself. > > What are the issues with such a secure download protocol? This > requires an AC to have a bootable image for every single WTP that the > AC wants to interoperate with. Which could be a matter of > differentiation for the AC vendors. If one vendor supports 2 models of > WTPs, while another one decides to support 10, then the marketplace > could choose if they like the feature set of the former enough that > they dont mind the reduced set of interoperable WTPs or whether they > like the greater interoperability of the latter AC. Secondly, we need > a mechanism for the WTP and the AC, soon after the discovery process, > to create a trust relationship between each other so that the WTP is > sure it is not downloading code from a malicious entity masquerading > as an AC and the AC is sure it is not supplying code to an entity > masquerading as a WTP. > > The secure download approach shifts the burden of interoperability to > the AC vendors and lowers the barrier for the WTP vendors that strive > for interoperability. This shift is fine since the AC is the center of > control and management for a WLAN and it is in the AC vendor's > interests to get to wider interoperability, if they so chose to > do. This is also aligned with the current market reality where the AC > vendors' capabilities determine what features are available on the > WLAN. The WTP vendors are required to implement a simpler protocol to > get to interoperability with multiple AC vendors. The level of > interoperability is always determined by individual choices by the > vendors. For example, an AC that only supports split MAC may not > interoperate with a WTP that only suppports the local MAC. Arguably, > the interoperability achievable by the secure download approach is no > worse than what is possible with a full-blown control protocol. Not to > mention the simplicity of the protocol that the CAPWAP WG needs to > work on. > > We intend to submit a proposal along these lines to the CAPWAP WG. It > will involve a simple process as follows: > - a WTP discovers one or more ACs, > - the WTP identifies itself to the ACs that it discovered, > - the WTP and one of the ACs create a mutual trust relationship, and > - the WTP downloading an image from an AC. > The details will be present in the draft that will follow soon. > > This approach is quite different from what has been discussed in the > WG so far. It probably also has implications on the objectives > draft. I would like to initiate some discussion on whether all the > mandatory objectives as stated in the current objectives draft are > still valid. I understand that the objectives were stated with a > full-fledged, open and/or externally verifiable protocol in mind. If a > certain set of objectives precludes such a simpler solution then we > may need to re-visit and discuss that set of objectives. In other > words, if a set of objectives as they currently stand are unnecessary > for solving the problem that we started out to address, then we should > discuss these now. > > Thanks > partha > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 14:29:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10335 for ; Wed, 9 Mar 2005 14:29:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CD33C205F0; Wed, 9 Mar 2005 14:29:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0BEEA20599; Wed, 9 Mar 2005 14:29:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF93920599 for ; Wed, 9 Mar 2005 14:28:59 -0500 (EST) Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by mail.frascone.com (Postfix) with ESMTP id 7172520577 for ; Wed, 9 Mar 2005 14:28:56 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUkyTkZeOJkvi+lQLCb7JYxtzARZAAEa9xg From: "Victor Lin" To: "Partha Narasimhan" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 11:28:51 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Partha, I think this approach works nice if both WTP and AC hardware are supplied by single vender. But if a user wants to buy AC and WTP from different venders, he or she will need to ask AC vender if they have a version of firmware that supports the WTP he or she wishes to use.=20 Since different WTPs might use different processors, WLAN MAC/PHY/Radios, and even different ways to control antenna switches, AC venders need to provide multiple WTP images to support different types of WTPs. It is possible to create "hardware abstraction layer" in CAPWAP-compatible WTP so common firmware can be used to run on different WTPs. Some operation systems, like Windows NT, use this approach to support different hardware. But still, different firmware will need to be created to support different processor architecture - unless JAVA-type of virtual machine is implemented on WTP so it can hide processor architecture from WTP firmware. Victor -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Partha Narasimhan Sent: Wednesday, March 09, 2005 8:59 AM To: capwap@frascone.com Subject: [Capwap] A simpler approach to CAPWAP The primary reason for the existence of the CAPWAP group is to solve an interoperability problem between ACs and WTPs from different vendors so that an end-user/customer has the choice of purchasing WTPs and ACs from different vendors. The existing marketplace is full of single-vendor solutions. To that extent, if an end-user is able to purchase a WTP from a vendor that is different than the vendor supplying the AC, but get them to interoperate with each other to create a functioning WLAN, then the end-user's objective is largely accomplished. Based on existing single-vendor WLAN solutions, it is obvious that the AC is where most of the control and management intelligence resides. It is not far from the truth to state the AC determines what functions are turned on at the WTPs and, hence, what features are available in the WLAN. Arguably, the interoperability problem can be restated as a customer's need to find WTPs that interoperate with his/her choice of AC. Or at a minimum, the WTPs need to follow and interoperate with the AC rather than the other way around.=20 Interoperability can be achieved at multiple levels. In most of the current discussion on the CAPWAP mailing list, the primary assumption seems to be that interoperability requirement seems to be between the individual software that both the WTP and the AC ship with and/or boot up with. Once both the devices are up and running with their images, the WTPs discover one or more ACs and, assuming everything is set up right, one of the discovered ACs will configure and bring up the WTP as part of the customer's WLAN using a protocol that will be defined as part of the CAPWAP WG's work. Interoperability can also be achieved using a simpler mechanism where a WTP boots up, discovers one or more ACs to create an association with. As part of the discovery process, the WTP identifies itself (vendor ID, hardware version, software version, etc.). One of the discovered ACs can then instruct the WTP to download a firmware image that the WTP should boot itself with at the end of the download process. Upon booting itself with this downloaded image, the WTP runs a protocol, quite possibly proprietary to the AC vendor, contained in the downloaded image to create an association with an AC and get configured to be a member of the WLAN. An AC from one vendor might download an image to a WTP that is completely different than an AC from another vendor. This does solve the end-user's requirement of getting interoperability between WTPs and ACs from different vendors. The control protocol used to get the WTP to become a member of the WLAN controlled and managed by the AC is totally upto the AC vendor's choice. Essentially, the solution becomes a simple protocol for the WTP to discover one or more ACs, identify itself to the ACs, and download an image from the AC, if possible, that it will boot itself with - a secure download problem rather than a WLAN configuration problem from an interoperability perspective. This solves the CAPWAP problem of interoperability without requiring a full-fledged, new control protocol that all the WTP and AC vendors have to implement for interoperability. It is sufficient to implement the simpler secure download protocol to get to interoperability. This removes the necessity to negotiate capabilities (split MAC vs local MAC, one person's split may not suit another but we cannot have infinite permutations of a split, etc.) since the WTP assumes capabilities that are contained in the image that the AC vendor chooses to build for it. Another benefit of this approach is the extensibility of this simpler approach to future wireless technologies or extensions to existing technologies since these are folded into the downloaded image and hence are transparent to the secure download protocol itself. What are the issues with such a secure download protocol? This requires an AC to have a bootable image for every single WTP that the AC wants to interoperate with. Which could be a matter of differentiation for the AC vendors. If one vendor supports 2 models of WTPs, while another one decides to support 10, then the marketplace could choose if they like the feature set of the former enough that they dont mind the reduced set of interoperable WTPs or whether they like the greater interoperability of the latter AC. Secondly, we need a mechanism for the WTP and the AC, soon after the discovery process, to create a trust relationship between each other so that the WTP is sure it is not downloading code from a malicious entity masquerading as an AC and the AC is sure it is not supplying code to an entity masquerading as a WTP.=20 The secure download approach shifts the burden of interoperability to the AC vendors and lowers the barrier for the WTP vendors that strive for interoperability. This shift is fine since the AC is the center of control and management for a WLAN and it is in the AC vendor's interests to get to wider interoperability, if they so chose to do. This is also aligned with the current market reality where the AC vendors' capabilities determine what features are available on the WLAN. The WTP vendors are required to implement a simpler protocol to get to interoperability with multiple AC vendors. The level of interoperability is always determined by individual choices by the vendors. For example, an AC that only supports split MAC may not interoperate with a WTP that only suppports the local MAC. Arguably, the interoperability achievable by the secure download approach is no worse than what is possible with a full-blown control protocol. Not to mention the simplicity of the protocol that the CAPWAP WG needs to work on. We intend to submit a proposal along these lines to the CAPWAP WG. It will involve a simple process as follows: - a WTP discovers one or more ACs, - the WTP identifies itself to the ACs that it discovered, - the WTP and one of the ACs create a mutual trust relationship, and - the WTP downloading an image from an AC. The details will be present in the draft that will follow soon. This approach is quite different from what has been discussed in the WG so far. It probably also has implications on the objectives draft. I would like to initiate some discussion on whether all the mandatory objectives as stated in the current objectives draft are still valid. I understand that the objectives were stated with a full-fledged, open and/or externally verifiable protocol in mind. If a certain set of objectives precludes such a simpler solution then we may need to re-visit and discuss that set of objectives. In other words, if a set of objectives as they currently stand are unnecessary for solving the problem that we started out to address, then we should discuss these now. Thanks partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 14:31:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10535 for ; Wed, 9 Mar 2005 14:31:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F12A205F0; Wed, 9 Mar 2005 14:31:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B83AF205B9; Wed, 9 Mar 2005 14:31:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1CF49205B9 for ; Wed, 9 Mar 2005 14:31:00 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id B21D120577 for ; Wed, 9 Mar 2005 14:30:57 -0500 (EST) Message-ID: <01e601c524de$aa7c4e20$456015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Inderpreet Singh" , "'Partha Narasimhan'" , References: <008e01c524d4$a5132850$c305a8c0@toronto.chantrynetworks.com> Subject: Re: : Re: [Capwap] A simpler approach to CAPWAP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 11:31:52 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Inderpreet, >James, I agree that firmware download is a nice to have. I am trying to >rationalize the work that might potentially go on in defining yet another >method of firmware download in the context of CAPWAP. How is the firmware >download problem different and unique in the case of WTPs vs. routers, >switches, printers, or any other networking device? It's different because routers, switches and printers aren't acting as controllers for other devices. The interfaces between these devices and others are peer interfaces. If there's a firmware mismatch between the WTPs and AC, the net might not work. With printers, etc., the device itself might fail to function, of course, but that won't influence whether other devices do. jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 14:38:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11769 for ; Wed, 9 Mar 2005 14:38:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 503F920611; Wed, 9 Mar 2005 14:38:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 74748205CE; Wed, 9 Mar 2005 14:38:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 79189205B9 for ; Wed, 9 Mar 2005 14:37:49 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id A6ED8205CE for ; Wed, 9 Mar 2005 14:37:46 -0500 (EST) Message-ID: <020501c524df$9de5d7c0$456015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Paul Lambert" , "Dan Harkins" Cc: "Partha Narasimhan" , "Michael Vakulenko" , References: <200503091922.j29JMrY1096382@homebrew.trpz.com> Subject: Re: [Capwap] A simpler approach to CAPWAP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 11:38:40 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Dan, > Let a Hundred Flowers Bloom! > Unfortunately, I don't think I could convince DoCoMo of the value in your botanical experiment to service providers, since the cost might come at their OPEX. :-) jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 14:39:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11845 for ; Wed, 9 Mar 2005 14:39:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 52582205EB; Wed, 9 Mar 2005 14:39:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 042C3205F0; Wed, 9 Mar 2005 14:39:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 188C2205EB for ; Wed, 9 Mar 2005 14:38:02 -0500 (EST) Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by mail.frascone.com (Postfix) with ESMTP id 4E6C9205B9 for ; Wed, 9 Mar 2005 14:37:59 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: : Re: [Capwap] A simpler approach to CAPWAP X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: : Re: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUk3pLVZyDZpcY1RYmJB60v/f8UGAAAGhWA From: "Victor Lin" To: "James Kempf" , "Inderpreet Singh" , "Partha Narasimhan" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 11:37:56 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I think firmware management is an important feature for AC to support, thus having standardized protocol between WTP and AC to handle this task will reduce the operation overhead of WLAN. Victor=20 -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Wednesday, March 09, 2005 11:32 AM To: Inderpreet Singh; 'Partha Narasimhan'; capwap@frascone.com Subject: Re: : Re: [Capwap] A simpler approach to CAPWAP Inderpreet, >James, I agree that firmware download is a nice to have. I am trying to >rationalize the work that might potentially go on in defining yet another >method of firmware download in the context of CAPWAP. How is the firmware >download problem different and unique in the case of WTPs vs. routers, >switches, printers, or any other networking device? It's different because routers, switches and printers aren't acting as controllers for other devices. The interfaces between these devices and others are peer interfaces. If there's a firmware mismatch between the WTPs and AC, the net might not work. With printers, etc., the device itself might fail to function, of course, but that won't influence whether other devices do. jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 14:55:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13314 for ; Wed, 9 Mar 2005 14:55:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E031C2043B; Wed, 9 Mar 2005 14:55:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 76B9E20446; Wed, 9 Mar 2005 14:55:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F49D20421 for ; Wed, 9 Mar 2005 14:54:26 -0500 (EST) Received: from WNIMAIL.WoodsideNet.Com (wnifwl.woodsidenet.com [65.192.186.2]) by mail.frascone.com (Postfix) with ESMTP id 2333E202E6 for ; Wed, 9 Mar 2005 14:54:23 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: <3FFBC907DD03A34CA4410C5C745DEB1205C4DECB@wnimail.WoodsideNet.Com> Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUk3bS0jrpUNlfbSfeS2XLXfUC4ZAAAI0pQ From: "Paul Lambert" To: "Dan Harkins" Cc: "Michael Vakulenko" , , "Partha Narasimhan" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 11:54:21 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable An interesting perspective... =20 Open standards allow products to be created without establishing direct business relationships with other participating vendors. Products should be able to interoperate in a system, based solely on the signaling defined in the standard. =20 For example, my mail reader can connect by SMTP or IMAP to a large number of standards compliant servers. This download approach is more like web-based applications that download code to the target workstation. You can read mail using proprietary communication protocols because you've downloaded a special proprietary applet. This sort-of works because there are standard in the execution environment (Java, JavaScript, ActiveX, Explorer, etc.) that allows some commonality in the downloaded application. For the WPT, this is a more difficult and diverse environment. These embedded systems run various operating systems and hardware architectures. If the proposal included the use of J2ME or some other standardized execution environment, then there might be merit in the concept. This environment would then also need to be extended to provide APIs for the appropriate WTP functionality. I am not hearing any such detail in the proposal. Proprietary downloads create chameleon WTPs. This is effectively allows the re-branding of devices by changing the firmware. In the field, this would provide little value. It's unlikely that such a WTP would switch identities after it was first installed. You might as well just load the appropriate firmware in the factory. =20 So, we already have this 'Hundred Flower Blooming' market. Every vendor has their own set of protocols. I can already sell hardware with different firmware images to various AC vendors. If this is the only requirement for CAPWAP, then we're done and should declare success and disband the committee. Paul =20 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com]=20 > Sent: Wednesday, March 09, 2005 11:23 AM > To: Paul Lambert > Cc: Partha Narasimhan; Michael Vakulenko; capwap@frascone.com > Subject: Re: [Capwap] A simpler approach to CAPWAP=20 >=20 > Paul, >=20 > I don't think it's designed to replace other control functionality. > The point is that it is not necessary to standardize that=20 > control functionality. The control functionality (and how and=20 > where to split a MAC, for instance) is all contained in the=20 > code running on the AC and the code in the image the AC=20 > provides to the WTP. How the control plane and data=20 > encapsulation are defined is up to the AC vendor (who wrote=20 > the code for running on the AC and also the code in the image=20 > provided to the WTC) and not to the IETF. >=20 > Let a Hundred Flowers Bloom! >=20 > Dan. >=20 > On Wed, 09 Mar 2005 11:14:39 PST you wrote > >=20 > > This 'simpler' approach would never work as propoposed to replace=20 > > other control functioanlity. > >=20 > > A software upgrade mechanism might be desireable. This upgrade=20 > > process would never replace a fuller set of control protocols. > >=20 > >=20 > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Partha Narasimhan > > > Sent: Wednesday, March 09, 2005 11:06 AM > > > To: Michael Vakulenko > > > Cc: capwap@frascone.com > > > Subject: RE: [Capwap] A simpler approach to CAPWAP > > >=20 > > > Just to clarify.... > > >=20 > > > This moves the onus of interoperability onto the AC vendors.=20 > > > They make images for a set of WTPs that they want to interoperate=20 > > > with. > >=20 > > The AC vendor may not have the desire or the bandwidth to make WTP=20 > > images. > >=20 > > Unless the WTP are on standardized hardwar, how would a AC vendor=20 > > build an image? > >=20 > > >The WTP vendors just have to implement a protocol where they=20 > > >discover ACs, identify themselves, and have the ability=20 > to download=20 > > >an image and boot themselves with it. The original image on WTP=20 > > >could do other things (the WTP vendor's choice) with=20 > their installed=20 > > >images in an environment where they are unable to discover an AC. > > >=20 > > > We are not calling for specifying how a WTP is built or with what=20 > > > components. Once it is built, every AC vendor that wants that=20 > > > particular model of WTP to work with needs to work with that WTP=20 > > > vendor and create their own version of a downloadable=20 > image for that=20 > > > board. > >=20 > > This is NOT the nature of open interoperable standards. A Company=20 > > should not have to work directly with every other vendor to create=20 > > interoperable systems. > >=20 > > Paul > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 15:29:21 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17317 for ; Wed, 9 Mar 2005 15:29:20 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8BE192061B; Wed, 9 Mar 2005 15:29:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F3A18205CE; Wed, 9 Mar 2005 15:29:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF350205CE for ; Wed, 9 Mar 2005 15:28:46 -0500 (EST) Received: from aruba-server.arubanetworks.com (216-31-249-252.cust.telepacific.net [216.31.249.252]) by mail.frascone.com (Postfix) with SMTP id AE3B920454 for ; Wed, 9 Mar 2005 15:28:43 -0500 (EST) Received: from [10.3.9.229] ([10.3.9.229] unverified) by aruba-server.arubanetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Mar 2005 12:28:42 -0800 Message-ID: <422F5C75.9030905@arubanetworks.com> From: Partha Narasimhan User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Harkins Cc: Paul Lambert , Michael Vakulenko , capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP References: <200503091922.j29JMrY1096382@homebrew.trpz.com> In-Reply-To: <200503091922.j29JMrY1096382@homebrew.trpz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2005 20:28:42.0249 (UTC) FILETIME=[95B23790:01C524E6] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 09 Mar 2005 12:28:37 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit To add to Dan's comments, if we look at the landscape of AC vendors today, there is a non-trivial amount of feature differentiation that is offered by them. To imagine that a CAPWAP proposal could create hooks to turn on or off a union of this feature set is unthinkable. Unless we are willing to spend lots and lots of time on it, we are limited to specifying a CAPWAP feature set that would look more like the intersection of the individual feature sets offered by all the AC vendors today - essentially, the bare minimum. If the marketplace requires more than that bare minimum, it is forced to go with a single-vendor solution. At which point all the noble objectives that CAPWAP started out with would have been nullified since an interoperable solution has not suit the end-users' needs. With the proposed solution, the AC vendors choose the feature set that would be present in a multi-vendor solution. I have to imagine that would be more than the bare minimum that a CAPWAP protocol would standardize on. Thanks partha Dan Harkins wrote: > Paul, > > I don't think it's designed to replace other control functionality. >The point is that it is not necessary to standardize that control >functionality. The control functionality (and how and where to split >a MAC, for instance) is all contained in the code running on the AC >and the code in the image the AC provides to the WTP. How the control >plane and data encapsulation are defined is up to the AC vendor (who >wrote the code for running on the AC and also the code in the image >provided to the WTC) and not to the IETF. > > Let a Hundred Flowers Bloom! > > Dan. > >On Wed, 09 Mar 2005 11:14:39 PST you wrote > > >>This 'simpler' approach would never work as propoposed to >>replace other control functioanlity. >> >>A software upgrade mechanism might be desireable. This >>upgrade process would never replace a fuller set of control protocols. >> >> >> >> >>>-----Original Message----- >>>From: capwap-admin@frascone.com >>>[mailto:capwap-admin@frascone.com] On Behalf Of Partha Narasimhan >>>Sent: Wednesday, March 09, 2005 11:06 AM >>>To: Michael Vakulenko >>>Cc: capwap@frascone.com >>>Subject: RE: [Capwap] A simpler approach to CAPWAP >>> >>>Just to clarify.... >>> >>>This moves the onus of interoperability onto the AC vendors. >>>They make images for a set of WTPs that they want to >>>interoperate with. >>> >>> >>The AC vendor may not have the desire or the bandwidth to make WTP >>images. >> >>Unless the WTP are on standardized hardwar, how would a AC vendor build >>an image? >> >> >> >>>The WTP vendors just have to implement a >>>protocol where they discover ACs, identify themselves, and >>>have the ability to download an image and boot themselves >>>with it. The original image on WTP could do other things (the >>>WTP vendor's choice) with their installed images in an >>>environment where they are unable to discover an AC. >>> >>>We are not calling for specifying how a WTP is built or with >>>what components. Once it is built, every AC vendor that wants >>>that particular model of WTP to work with needs to work with >>>that WTP vendor and create their own version of a >>>downloadable image for that board. >>> >>> >>This is NOT the nature of open interoperable standards. A >>Company should not have to work directly with every other vendor >>to create interoperable systems. >> >>Paul >>_______________________________________________ >>Capwap mailing list >>Capwap@frascone.com >>http://mail.frascone.com/mailman/listinfo/capwap >> >> >> _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 15:32:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17652 for ; Wed, 9 Mar 2005 15:32:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F8F220628; Wed, 9 Mar 2005 15:32:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C357E2060B; Wed, 9 Mar 2005 15:32:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 304282060B for ; Wed, 9 Mar 2005 15:31:29 -0500 (EST) Received: from aruba-server.arubanetworks.com (216-31-249-253.cust.telepacific.net [216.31.249.253]) by mail.frascone.com (Postfix) with SMTP id CDB3F205CE for ; Wed, 9 Mar 2005 15:31:25 -0500 (EST) Received: from [10.3.9.229] ([10.3.9.229] unverified) by aruba-server.arubanetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Mar 2005 12:31:23 -0800 Message-ID: <422F5D17.60003@arubanetworks.com> From: Partha Narasimhan User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Victor Lin Cc: capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2005 20:31:24.0011 (UTC) FILETIME=[F61D23B0:01C524E6] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 09 Mar 2005 12:31:19 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Victor, The proposal here is to have the AC vendors control the firmware that is downloaded into the WTP. We are not attempting to achieve interoperability with the original firmware that the WTP manufacturer decided to ship the box with. I agree that AC vendors may have to support firmware images for multiple types of WTPs. For every kind of WTP that an AC vendor wants to support, they would have to create an image for it. Maybe thats a way they create differentiation in the marketplace. And it could lead to a natural selection process among the population of WTPs. More importantly, it is possible to keep any WLAN related details out of the discover and download protocol so that it is easily extensible to other wireless technologies or any other problem that requires a bunch of network elements to be controlled by a controller. Thanks partha Victor Lin wrote: >Partha, > >I think this approach works nice if both WTP and AC hardware are >supplied by single vender. But if a user wants to buy AC and WTP from >different venders, he or she will need to ask AC vender if they have a >version of firmware that supports the WTP he or she wishes to use. > >Since different WTPs might use different processors, WLAN >MAC/PHY/Radios, and even different ways to control antenna switches, AC >venders need to provide multiple WTP images to support different types >of WTPs. It is possible to create "hardware abstraction layer" in >CAPWAP-compatible WTP so common firmware can be used to run on different >WTPs. Some operation systems, like Windows NT, use this approach to >support different hardware. But still, different firmware will need to >be created to support different processor architecture - unless >JAVA-type of virtual machine is implemented on WTP so it can hide >processor architecture from WTP firmware. > >Victor > > > >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >Behalf Of Partha Narasimhan >Sent: Wednesday, March 09, 2005 8:59 AM >To: capwap@frascone.com >Subject: [Capwap] A simpler approach to CAPWAP > > >The primary reason for the existence of the CAPWAP group is to solve >an interoperability problem between ACs and WTPs from different >vendors so that an end-user/customer has the choice of purchasing WTPs >and ACs from different vendors. The existing marketplace is full of >single-vendor solutions. To that extent, if an end-user is able to >purchase a WTP from a vendor that is different than the vendor >supplying the AC, but get them to interoperate with each other to >create a functioning WLAN, then the end-user's objective is largely >accomplished. > >Based on existing single-vendor WLAN solutions, it is obvious that the >AC is where most of the control and management intelligence >resides. It is not far from the truth to state the AC determines what >functions are turned on at the WTPs and, hence, what features are >available in the WLAN. Arguably, the interoperability problem can be >restated as a customer's need to find WTPs that interoperate with >his/her choice of AC. Or at a minimum, the WTPs need to follow and >interoperate with the AC rather than the other way around. > >Interoperability can be achieved at multiple levels. In most of the >current discussion on the CAPWAP mailing list, the primary assumption >seems to be that interoperability requirement seems to be between the >individual software that both the WTP and the AC ship with and/or boot >up with. Once both the devices are up and running with their images, >the WTPs discover one or more ACs and, assuming everything is set up >right, one of the discovered ACs will configure and bring up the WTP >as part of the customer's WLAN using a protocol that will be defined >as part of the CAPWAP WG's work. > >Interoperability can also be achieved using a simpler mechanism where >a WTP boots up, discovers one or more ACs to create an association >with. As part of the discovery process, the WTP identifies itself >(vendor ID, hardware version, software version, etc.). One of the >discovered ACs can then instruct the WTP to download a firmware image >that the WTP should boot itself with at the end of the download >process. Upon booting itself with this downloaded image, the WTP runs >a protocol, quite possibly proprietary to the AC vendor, contained in >the downloaded image to create an association with an AC and get >configured to be a member of the WLAN. An AC from one vendor might >download an image to a WTP that is completely different than an AC >from another vendor. This does solve the end-user's requirement of >getting interoperability between WTPs and ACs from different >vendors. The control protocol used to get the WTP to become a member >of the WLAN controlled and managed by the AC is totally upto the AC >vendor's choice. > >Essentially, the solution becomes a simple protocol for the WTP to >discover one or more ACs, identify itself to the ACs, and download an >image from the AC, if possible, that it will boot itself with - a >secure download problem rather than a WLAN configuration problem from >an interoperability perspective. This solves the CAPWAP problem of >interoperability without requiring a full-fledged, new control >protocol that all the WTP and AC vendors have to implement for >interoperability. It is sufficient to implement the simpler secure >download protocol to get to interoperability. This removes the >necessity to negotiate capabilities (split MAC vs local MAC, one >person's split may not suit another but we cannot have infinite >permutations of a split, etc.) since the WTP assumes capabilities that >are contained in the image that the AC vendor chooses to build for >it. Another benefit of this approach is the extensibility of this >simpler approach to future wireless technologies or extensions to >existing technologies since these are folded into the downloaded image >and hence are transparent to the secure download protocol itself. > >What are the issues with such a secure download protocol? This >requires an AC to have a bootable image for every single WTP that the >AC wants to interoperate with. Which could be a matter of >differentiation for the AC vendors. If one vendor supports 2 models of >WTPs, while another one decides to support 10, then the marketplace >could choose if they like the feature set of the former enough that >they dont mind the reduced set of interoperable WTPs or whether they >like the greater interoperability of the latter AC. Secondly, we need >a mechanism for the WTP and the AC, soon after the discovery process, >to create a trust relationship between each other so that the WTP is >sure it is not downloading code from a malicious entity masquerading >as an AC and the AC is sure it is not supplying code to an entity >masquerading as a WTP. > >The secure download approach shifts the burden of interoperability to >the AC vendors and lowers the barrier for the WTP vendors that strive >for interoperability. This shift is fine since the AC is the center of >control and management for a WLAN and it is in the AC vendor's >interests to get to wider interoperability, if they so chose to >do. This is also aligned with the current market reality where the AC >vendors' capabilities determine what features are available on the >WLAN. The WTP vendors are required to implement a simpler protocol to >get to interoperability with multiple AC vendors. The level of >interoperability is always determined by individual choices by the >vendors. For example, an AC that only supports split MAC may not >interoperate with a WTP that only suppports the local MAC. Arguably, >the interoperability achievable by the secure download approach is no >worse than what is possible with a full-blown control protocol. Not to >mention the simplicity of the protocol that the CAPWAP WG needs to >work on. > >We intend to submit a proposal along these lines to the CAPWAP WG. It >will involve a simple process as follows: >- a WTP discovers one or more ACs, >- the WTP identifies itself to the ACs that it discovered, >- the WTP and one of the ACs create a mutual trust relationship, and >- the WTP downloading an image from an AC. >The details will be present in the draft that will follow soon. > >This approach is quite different from what has been discussed in the >WG so far. It probably also has implications on the objectives >draft. I would like to initiate some discussion on whether all the >mandatory objectives as stated in the current objectives draft are >still valid. I understand that the objectives were stated with a >full-fledged, open and/or externally verifiable protocol in mind. If a >certain set of objectives precludes such a simpler solution then we >may need to re-visit and discuss that set of objectives. In other >words, if a set of objectives as they currently stand are unnecessary >for solving the problem that we started out to address, then we should >discuss these now. > >Thanks >partha >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 15:53:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19611 for ; Wed, 9 Mar 2005 15:53:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7440920628; Wed, 9 Mar 2005 15:53:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD0B52045B; Wed, 9 Mar 2005 15:53:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BFF332045B for ; Wed, 9 Mar 2005 15:52:55 -0500 (EST) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 53E1B20447 for ; Wed, 9 Mar 2005 15:52:49 -0500 (EST) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j29KoHIG096861; Wed, 9 Mar 2005 12:50:22 -0800 (PST) (envelope-from dharkins@trpz.com) Message-Id: <200503092050.j29KoHIG096861@homebrew.trpz.com> To: "James Kempf" Cc: "Paul Lambert" , "Partha Narasimhan" , "Michael Vakulenko" , capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP In-Reply-To: Your message of "Wed, 09 Mar 2005 11:38:40 PST." <020501c524df$9de5d7c0$456015ac@dcml.docomolabsusa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <96859.1110401417.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 09 Mar 2005 12:50:17 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Well it's a Chairman Mao quote so it might cause other problems for them as well. I fail to see the cost you are imagining. Dan. On Wed, 09 Mar 2005 11:38:40 PST you wrote > Hi Dan, > > > Let a Hundred Flowers Bloom! > > > > Unfortunately, I don't think I could convince DoCoMo of the value in your > botanical experiment to service providers, since the cost might come at > their OPEX. :-) > > jak > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 16:18:06 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21196 for ; Wed, 9 Mar 2005 16:18:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C611D20631; Wed, 9 Mar 2005 16:18:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E62D1205CE; Wed, 9 Mar 2005 16:18:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 846D82062E for ; Wed, 9 Mar 2005 16:17:22 -0500 (EST) Received: from WNIMAIL.WoodsideNet.Com (wnifwl.woodsidenet.com [65.192.186.2]) by mail.frascone.com (Postfix) with ESMTP id 96AA420466 for ; Wed, 9 Mar 2005 16:17:19 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: <3FFBC907DD03A34CA4410C5C745DEB1205C4DEF9@wnimail.WoodsideNet.Com> Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUk5pZqV/rpORcdT/yCVXM2bVg6CwABj/+g From: "Paul Lambert" To: "Partha Narasimhan" , "Dan Harkins" Cc: "Michael Vakulenko" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 13:17:15 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Partha Narasimhan [mailto:partha@arubanetworks.com]=20 >=20 > To add to Dan's comments, if we look at the landscape of AC=20 > vendors today, there is a non-trivial amount of feature=20 > differentiation that is offered by them. To imagine that a=20 > CAPWAP proposal could create hooks to turn on or off a union=20 > of this feature set is unthinkable. Unless we are willing to=20 > spend lots and lots of time on it, we are limited to=20 > specifying a CAPWAP feature set that would look more like the=20 > intersection of the individual feature sets offered by all=20 > the AC vendors today - essentially, the bare minimum. If the=20 > marketplace requires more than that bare minimum, it is=20 > forced to go with a single-vendor solution.=20 No! The minimum set can provide basic interoperability. Additional features are readily provided by extensions in protocol signaling. Worked examples include SNMP and IEEE 802.11 (the IEs). Paul _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 16:18:28 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21227 for ; Wed, 9 Mar 2005 16:18:27 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9BB682062E; Wed, 9 Mar 2005 16:18:27 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 55DF120635; Wed, 9 Mar 2005 16:18:12 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A23A20466 for ; Wed, 9 Mar 2005 16:17:23 -0500 (EST) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id C24A7205CE for ; Wed, 9 Mar 2005 16:17:21 -0500 (EST) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j29LF50E096948; Wed, 9 Mar 2005 13:15:05 -0800 (PST) (envelope-from dharkins@trpz.com) Message-Id: <200503092115.j29LF50E096948@homebrew.trpz.com> To: "Paul Lambert" Cc: "Michael Vakulenko" , capwap@frascone.com, "Partha Narasimhan" Subject: Re: [Capwap] A simpler approach to CAPWAP In-Reply-To: Your message of "Wed, 09 Mar 2005 11:54:21 PST." <3FFBC907DD03A34CA4410C5C745DEB1205C4DECB@wnimail.WoodsideNet.Com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <96946.1110402905.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 09 Mar 2005 13:15:05 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Wed, 09 Mar 2005 11:54:21 PST you wrote > > So, we already have this 'Hundred Flower Blooming' market. Every vendor > has their own set of protocols. I can already sell hardware with > different firmware images to various AC vendors. But then you support different firmware images for different venders. What a pain. Why not just support one that speaks a standard discovery-and-download protocol? At the start of this working group people were talking about the commoditization of APs and how they'd be sold by for low margins in bulk. The discover-and-download idea fits perfectly in with that. It also enables innovation and product differentiation. It allows for extensibility in a way than the alternative (define a huge, generic control plane and data encapsulation that encompasses all possible architectures in the taxonomy draft) cannot handle. > If this is the only > requirement for CAPWAP, then we're done and should declare success and > disband the committee. Now we're talking! I haven't seen this kind of attitude since the OTP working group! The alternative is yet another indefinite working group that sews new limbs on the frankenstein monster as new options and new technologies emerge. Dan. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 16:34:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22846 for ; Wed, 9 Mar 2005 16:34:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8B6A820636; Wed, 9 Mar 2005 16:34:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C133F2061B; Wed, 9 Mar 2005 16:34:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7E4AC2061B for ; Wed, 9 Mar 2005 16:33:47 -0500 (EST) Received: from WNIMAIL.WoodsideNet.Com (wnifwl.woodsidenet.com [65.192.186.2]) by mail.frascone.com (Postfix) with ESMTP id 4CF59205CE for ; Wed, 9 Mar 2005 16:33:44 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: <3FFBC907DD03A34CA4410C5C745DEB1205C4DEFE@wnimail.WoodsideNet.Com> Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUk7WCSj+5udRZCRrGVQNXYv/fCFwAAB9Ug From: "Paul Lambert" To: "Dan Harkins" Cc: "Michael Vakulenko" , , "Partha Narasimhan" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 13:33:43 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@trpz.com]=20 > Sent: Wednesday, March 09, 2005 1:15 PM > To: Paul Lambert > Cc: Michael Vakulenko; capwap@frascone.com; Partha Narasimhan > Subject: Re: [Capwap] A simpler approach to CAPWAP=20 >=20 > On Wed, 09 Mar 2005 11:54:21 PST you wrote > >=20 > > So, we already have this 'Hundred Flower Blooming' market. Every=20 > > vendor has their own set of protocols. I can already sell hardware=20 > > with different firmware images to various AC vendors. >=20 > But then you support different firmware images for=20 > different venders. > What a pain. Why not just support one that speaks a standard=20 > discovery-and-download protocol?=20 But you would still need differnet firmware for each different AC vendor. There is no diffierence except a slightly different=20 boot sequence. =20 > Now we're talking! I haven't seen this kind of attitude=20 > since the OTP working group! The alternative is yet another=20 > indefinite working group that sews new limbs on the=20 > frankenstein monster as new options and new technologies emerge. Thanks :-) It was supposed to be sarcasm... I see having only this download/bootstrap process as equivalent to throwing away the CAPWAP requirements. On a positive note, having a simple secure bootstrapping protocol would be great for this type of product market. It would be a useful result for the committee; it just would not provide an open playing field that a true set of open signaling would create. =20 Discovery and bootstrapping the firmware is at least an interesting stating point. I'd hope that the same process could also provide some manner of control signaling. And yes, the current requirements of the working group could become a multi-armed monster protocol. =20 Paul _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 16:46:12 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24143 for ; Wed, 9 Mar 2005 16:46:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E1F1D20644; Wed, 9 Mar 2005 16:46:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3224520638; Wed, 9 Mar 2005 16:46:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 046AD1FC64 for ; Wed, 9 Mar 2005 16:45:07 -0500 (EST) Received: from smtp110.mail.sc5.yahoo.com (smtp110.mail.sc5.yahoo.com [66.163.170.8]) by mail.frascone.com (Postfix) with SMTP id 614B520638 for ; Wed, 9 Mar 2005 16:45:04 -0500 (EST) Received: from unknown (HELO MICHAELV-LT.yahoo.com) (mvakulenko@212.179.88.120 with login) by smtp110.mail.sc5.yahoo.com with SMTP; 9 Mar 2005 21:45:01 -0000 Message-Id: <6.2.1.2.0.20050309230427.045f1ac0@pop.mail.yahoo.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 To: Dan Harkins From: Michael Vakulenko Subject: Re: [Capwap] A simpler approach to CAPWAP Cc: capwap@frascone.com In-Reply-To: <200503091912.j29JCHwh096319@homebrew.trpz.com> References: <200503091912.j29JCHwh096319@homebrew.trpz.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_227677352==.ALT" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 09 Mar 2005 23:43:32 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --=====================_227677352==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:12 PM 3/9/2005, Dan Harkins wrote: > On the contrary. If the CAPWAP protocol defines a full control plane >and data frame encapsulation it will have to define standard APIs >that need to be supported by all interoperable WTPs. If we are referring to Application Programming Interface (API) here, I disagree with your comment. None of the well-known and widely used protocols (IP, TCP, FTP, HTTP, you name it) required definition of an API that have to go with the protocol. The whole point of defining a protocol is to decouple implementation from external interface. >If Partha's approach is taken then all that is defined is a discovery and >download protocol. The WTC runs the downloaded image and that contains the >(not-defined by CAPWAP) control and data frame protocols. I'm afraid you are over-simplifying it. This downloaded image is just a piece of object code for a specific processor instruction set, right? This piece of object code was created by compiling it with a specific compiler, linking it with appropriate libraries and storing it in some kind of a file format (e.g. ELF). Now this file has to be downloaded to the WTP memory and dynamically linked to the rest of the software running on the WTP. Once this is done, this piece of code can be finally activated and make calls to WTP API software, which in turn will exercise the actual hardware. All this is before mentioning such insignificant things as programming model (tasks, threads, semaphores, queues, memory management, etc.) and development tools needed for such an endeavor. Sorry for the tutorial, but it's going to be much simpler define CAPWAP protocol than deal with all these issues. > No we're not talking about Java. > > The practicalities of achieving interoperability are solely on >implementation of the discovery and download protocol. It is simple and >therefore acheiving interoperability would not be hard. Agreed. But what does this buy to us? >The practicalities of achieving stability and predictable performance are >borne by the AC vendors who will guarantee that the image they provide to >a WTP is stable and has predictable performance. I'm confused now. This statement defeats the (declared) motivation of this discussion: "...the interoperability problem can be restated as a customer's need to find WTPs that interoperate with his/her choice of AC. Or at a minimum, the WTPs need to follow and interoperate with the AC rather than the other way around. " Thanks, -- Michael V. www.WaveCompass.com > Dan. > >On Wed, 09 Mar 2005 20:45:25 +0200 you wrote > > Partha, > > > > I don't see how your suggestion makes things simpler. If CAPWAP would > > follow your approach, this WG had to define standard APIs that needs to be > > supported by all interoperable WTPs. These APIs will have to be quite > > low-level and detailed to provide interface to 802.11 chipset, Ethernet > > driver and operating system of the WTPs. > > > > Moreover, different WTP models may use different processor cores and > > therefore firmware object code cannot be the same for all WTPs. (We are > not > > talking about Java here, are we?.. :-) ) > > > > The real complexity of what you have proposed is in fact higher than > > traditional approach to protocol design, if you consider practicalities of > > achieving interoperability, stability and predictable performance for > > downloadable firmware. > > > > -- Michael V. > > http://www.WaveCompass.com > > > > > > At 06:58 PM 3/9/2005, Partha Narasimhan wrote: > > > > >The primary reason for the existence of the CAPWAP group is to solve > > >an interoperability problem between ACs and WTPs from different > > >vendors so that an end-user/customer has the choice of purchasing WTPs > > >and ACs from different vendors. The existing marketplace is full of > > >single-vendor solutions. To that extent, if an end-user is able to > > >purchase a WTP from a vendor that is different than the vendor > > >supplying the AC, but get them to interoperate with each other to > > >create a functioning WLAN, then the end-user's objective is largely > > >accomplished. > > > > > >Based on existing single-vendor WLAN solutions, it is obvious that the > > >AC is where most of the control and management intelligence > > >resides. It is not far from the truth to state the AC determines what > > >functions are turned on at the WTPs and, hence, what features are > > >available in the WLAN. Arguably, the interoperability problem can be > > >restated as a customer's need to find WTPs that interoperate with > > >his/her choice of AC. Or at a minimum, the WTPs need to follow and > > >interoperate with the AC rather than the other way around. > > > > > >Interoperability can be achieved at multiple levels. In most of the > > >current discussion on the CAPWAP mailing list, the primary assumption > > >seems to be that interoperability requirement seems to be between the > > >individual software that both the WTP and the AC ship with and/or boot > > >up with. Once both the devices are up and running with their images, > > >the WTPs discover one or more ACs and, assuming everything is set up > > >right, one of the discovered ACs will configure and bring up the WTP > > >as part of the customer's WLAN using a protocol that will be defined > > >as part of the CAPWAP WG's work. > > > > > >Interoperability can also be achieved using a simpler mechanism where > > >a WTP boots up, discovers one or more ACs to create an association > > >with. As part of the discovery process, the WTP identifies itself > > >(vendor ID, hardware version, software version, etc.). One of the > > >discovered ACs can then instruct the WTP to download a firmware image > > >that the WTP should boot itself with at the end of the download > > >process. Upon booting itself with this downloaded image, the WTP runs > > >a protocol, quite possibly proprietary to the AC vendor, contained in > > >the downloaded image to create an association with an AC and get > > >configured to be a member of the WLAN. An AC from one vendor might > > >download an image to a WTP that is completely different than an AC > > >from another vendor. This does solve the end-user's requirement of > > >getting interoperability between WTPs and ACs from different > > >vendors. The control protocol used to get the WTP to become a member > > >of the WLAN controlled and managed by the AC is totally upto the AC > > >vendor's choice. > > > > > >Essentially, the solution becomes a simple protocol for the WTP to > > >discover one or more ACs, identify itself to the ACs, and download an > > >image from the AC, if possible, that it will boot itself with - a > > >secure download problem rather than a WLAN configuration problem from > > >an interoperability perspective. This solves the CAPWAP problem of > > >interoperability without requiring a full-fledged, new control > > >protocol that all the WTP and AC vendors have to implement for > > >interoperability. It is sufficient to implement the simpler secure > > >download protocol to get to interoperability. This removes the > > >necessity to negotiate capabilities (split MAC vs local MAC, one > > >person's split may not suit another but we cannot have infinite > > >permutations of a split, etc.) since the WTP assumes capabilities that > > >are contained in the image that the AC vendor chooses to build for > > >it. Another benefit of this approach is the extensibility of this > > >simpler approach to future wireless technologies or extensions to > > >existing technologies since these are folded into the downloaded image > > >and hence are transparent to the secure download protocol itself. > > > > > >What are the issues with such a secure download protocol? This > > >requires an AC to have a bootable image for every single WTP that the > > >AC wants to interoperate with. Which could be a matter of > > >differentiation for the AC vendors. If one vendor supports 2 models of > > >WTPs, while another one decides to support 10, then the marketplace > > >could choose if they like the feature set of the former enough that > > >they dont mind the reduced set of interoperable WTPs or whether they > > >like the greater interoperability of the latter AC. Secondly, we need > > >a mechanism for the WTP and the AC, soon after the discovery process, > > >to create a trust relationship between each other so that the WTP is > > >sure it is not downloading code from a malicious entity masquerading > > >as an AC and the AC is sure it is not supplying code to an entity > > >masquerading as a WTP. > > > > > >The secure download approach shifts the burden of interoperability to > > >the AC vendors and lowers the barrier for the WTP vendors that strive > > >for interoperability. This shift is fine since the AC is the center of > > >control and management for a WLAN and it is in the AC vendor's > > >interests to get to wider interoperability, if they so chose to > > >do. This is also aligned with the current market reality where the AC > > >vendors' capabilities determine what features are available on the > > >WLAN. The WTP vendors are required to implement a simpler protocol to > > >get to interoperability with multiple AC vendors. The level of > > >interoperability is always determined by individual choices by the > > >vendors. For example, an AC that only supports split MAC may not > > >interoperate with a WTP that only suppports the local MAC. Arguably, > > >the interoperability achievable by the secure download approach is no > > >worse than what is possible with a full-blown control protocol. Not to > > >mention the simplicity of the protocol that the CAPWAP WG needs to > > >work on. > > > > > >We intend to submit a proposal along these lines to the CAPWAP WG. It > > >will involve a simple process as follows: > > >- a WTP discovers one or more ACs, > > >- the WTP identifies itself to the ACs that it discovered, > > >- the WTP and one of the ACs create a mutual trust relationship, and > > >- the WTP downloading an image from an AC. > > >The details will be present in the draft that will follow soon. > > > > > >This approach is quite different from what has been discussed in the > > >WG so far. It probably also has implications on the objectives > > >draft. I would like to initiate some discussion on whether all the > > >mandatory objectives as stated in the current objectives draft are > > >still valid. I understand that the objectives were stated with a > > >full-fledged, open and/or externally verifiable protocol in mind. If a > > >certain set of objectives precludes such a simpler solution then we > > >may need to re-visit and discuss that set of objectives. In other > > >words, if a set of objectives as they currently stand are unnecessary > > >for solving the problem that we started out to address, then we should > > >discuss these now. > > > > > >Thanks > > >partha > > >_______________________________________________ > > >Capwap mailing list > > >Capwap@frascone.com > > >http://mail.frascone.com/mailman/listinfo/capwap > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap --=====================_227677352==.ALT Content-Type: text/html; charset="us-ascii" At 09:12 PM 3/9/2005, Dan Harkins wrote:
  On the contrary. If the CAPWAP protocol defines a full control plane
and data frame encapsulation it will have to define standard APIs
that need to be supported by all interoperable WTPs.

If we are referring to Application Programming Interface (API) here, I disagree with your comment.

None of the well-known and widely used protocols (IP, TCP, FTP, HTTP, you name it) required definition of an API that have to go with the protocol. The whole point of defining a protocol is to decouple implementation from external interface.

If Partha's approach is taken then all that is defined is a discovery and download protocol. The WTC runs the downloaded image and that contains the
(not-defined by CAPWAP) control and data frame protocols.

I'm afraid you are over-simplifying it. This downloaded image is just a piece of object code for a specific processor instruction set, right? This piece of object code was created by compiling it with a specific compiler, linking it with appropriate libraries and storing it in some kind of a file format (e.g. ELF). Now this file has to be downloaded to the WTP memory and dynamically linked to the rest of the software running on the WTP. Once this is done, this piece of code can be finally activated and make calls to WTP API software, which in turn will exercise the actual hardware.

All this is before mentioning such insignificant things as programming model (tasks, threads, semaphores, queues, memory management, etc.) and development tools needed for such an endeavor.

Sorry for the tutorial, but it's going to be much simpler define CAPWAP protocol than deal with all these issues.

  No we're not talking about Java.

  The practicalities of achieving interoperability are solely on
implementation of the discovery and download protocol. It is simple and
therefore acheiving interoperability would not be hard.

Agreed. But what does this buy to us?

The practicalities of achieving stability and predictable performance are borne by the AC vendors who will guarantee that the image they provide to a WTP is stable and has predictable performance.

I'm confused now. This statement defeats the (declared) motivation of this discussion: "...the interoperability problem can be
restated as a customer's need to find WTPs that interoperate with
his/her choice of AC. Or at a minimum, the WTPs need to follow and
interoperate with the AC rather than the other way around. "


Thanks,

-- Michael V.
   www.WaveCompass.com


  Dan.

On Wed, 09 Mar 2005 20:45:25 +0200 you wrote
> Partha,
>
> I don't see how your suggestion makes things simpler. If CAPWAP would
> follow your approach, this WG had to define standard APIs that needs to be
> supported by all interoperable WTPs. These APIs will have to be quite
> low-level and detailed to provide interface to 802.11 chipset, Ethernet
> driver and operating system of the WTPs.
>
> Moreover, different WTP models may use different processor cores and
> therefore firmware object code cannot be the same for all WTPs. (We are not
> talking about Java here, are we?.. :-) )
>
> The real complexity of what you have proposed is in fact higher than
> traditional approach to protocol design, if you consider practicalities of
> achieving interoperability, stability and predictable performance for
> downloadable firmware.
>
> -- Michael V.
>     http://www.WaveCompass.com
>
>
> At 06:58 PM 3/9/2005, Partha Narasimhan wrote:
>
> >The primary reason for the existence of the CAPWAP group is to solve
> >an interoperability problem between ACs and WTPs from different
> >vendors so that an end-user/customer has the choice of purchasing WTPs
> >and ACs from different vendors. The existing marketplace is full of
> >single-vendor solutions. To that extent, if an end-user is able to
> >purchase a WTP from a vendor that is different than the vendor
> >supplying the AC, but get them to interoperate with each other to
> >create a functioning WLAN, then the end-user's objective is largely
> >accomplished.
> >
> >Based on existing single-vendor WLAN solutions, it is obvious that the
> >AC is where most of the control and management intelligence
> >resides. It is not far from the truth to state the AC determines what
> >functions are turned on at the WTPs and, hence, what features are
> >available in the WLAN. Arguably, the interoperability problem can be
> >restated as a customer's need to find WTPs that interoperate with
> >his/her choice of AC. Or at a minimum, the WTPs need to follow and
> >interoperate with the AC rather than the other way around.
> >
> >Interoperability can be achieved at multiple levels. In most of the
> >current discussion on the CAPWAP mailing list, the primary assumption
> >seems to be that interoperability requirement seems to be between the
> >individual software that both the WTP and the AC ship with and/or boot
> >up with. Once both the devices are up and running with their images,
> >the WTPs discover one or more ACs and, assuming everything is set up
> >right, one of the discovered ACs will configure and bring up the WTP
> >as part of the customer's WLAN using a protocol that will be defined
> >as part of the CAPWAP WG's work.
> >
> >Interoperability can also be achieved using a simpler mechanism where
> >a WTP boots up, discovers one or more ACs to create an association
> >with. As part of the discovery process, the WTP identifies itself
> >(vendor ID, hardware version, software version, etc.). One of the
> >discovered ACs can then instruct the WTP to download a firmware image
> >that the WTP should boot itself with at the end of the download
> >process. Upon booting itself with this downloaded image, the WTP runs
> >a protocol, quite possibly proprietary to the AC vendor, contained in
> >the downloaded image to create an association with an AC and get
> >configured to be a member of the WLAN. An AC from one vendor might
> >download an image to a WTP that is completely different than an AC
> >from another vendor. This does solve the end-user's requirement of
> >getting interoperability between WTPs and ACs from different
> >vendors. The control protocol used to get the WTP to become a member
> >of the WLAN controlled and managed by the AC is totally upto the AC
> >vendor's choice.
> >
> >Essentially, the solution becomes a simple protocol for the WTP to
> >discover one or more ACs, identify itself to the ACs, and download an
> >image from the AC, if possible, that it will boot itself with - a
> >secure download problem rather than a WLAN configuration problem from
> >an interoperability perspective. This solves the CAPWAP problem of
> >interoperability without requiring a full-fledged, new control
> >protocol that all the WTP and AC vendors have to implement for
> >interoperability. It is sufficient to implement the simpler secure
> >download protocol to get to interoperability. This removes the
> >necessity to negotiate capabilities (split MAC vs local MAC, one
> >person's split may not suit another but we cannot have infinite
> >permutations of a split, etc.) since the WTP assumes capabilities that
> >are contained in the image that the AC vendor chooses to build for
> >it. Another benefit of this approach is the extensibility of this
> >simpler approach to future wireless technologies or extensions to
> >existing technologies since these are folded into the downloaded image
> >and hence are transparent to the secure download protocol itself.
> >
> >What are the issues with such a secure download protocol? This
> >requires an AC to have a bootable image for every single WTP that the
> >AC wants to interoperate with. Which could be a matter of
> >differentiation for the AC vendors. If one vendor supports 2 models of
> >WTPs, while another one decides to support 10, then the marketplace
> >could choose if they like the feature set of the former enough that
> >they dont mind the reduced set of interoperable WTPs or whether they
> >like the greater interoperability of the latter AC. Secondly, we need
> >a mechanism for the WTP and the AC, soon after the discovery process,
> >to create a trust relationship between each other so that the WTP is
> >sure it is not downloading code from a malicious entity masquerading
> >as an AC and the AC is sure it is not supplying code to an entity
> >masquerading as a WTP.
> >
> >The secure download approach shifts the burden of interoperability to
> >the AC vendors and lowers the barrier for the WTP vendors that strive
> >for interoperability. This shift is fine since the AC is the center of
> >control and management for a WLAN and it is in the AC vendor's
> >interests to get to wider interoperability, if they so chose to
> >do. This is also aligned with the current market reality where the AC
> >vendors' capabilities determine what features are available on the
> >WLAN. The WTP vendors are required to implement a simpler protocol to
> >get to interoperability with multiple AC vendors. The level of
> >interoperability is always determined by individual choices by the
> >vendors. For example, an AC that only supports split MAC may not
> >interoperate with a WTP that only suppports the local MAC. Arguably,
> >the interoperability achievable by the secure download approach is no
> >worse than what is possible with a full-blown control protocol. Not to
> >mention the simplicity of the protocol that the CAPWAP WG needs to
> >work on.
> >
> >We intend to submit a proposal along these lines to the CAPWAP WG. It
> >will involve a simple process as follows:
> >- a WTP discovers one or more ACs,
> >- the WTP identifies itself to the ACs that it discovered,
> >- the WTP and one of the ACs create a mutual trust relationship, and
> >- the WTP downloading an image from an AC.
> >The details will be present in the draft that will follow soon.
> >
> >This approach is quite different from what has been discussed in the
> >WG so far. It probably also has implications on the objectives
> >draft. I would like to initiate some discussion on whether all the
> >mandatory objectives as stated in the current objectives draft are
> >still valid. I understand that the objectives were stated with a
> >full-fledged, open and/or externally verifiable protocol in mind. If a
> >certain set of objectives precludes such a simpler solution then we
> >may need to re-visit and discuss that set of objectives. In other
> >words, if a set of objectives as they currently stand are unnecessary
> >for solving the problem that we started out to address, then we should
> >discuss these now.
> >
> >Thanks
> >partha
> >_______________________________________________
> >Capwap mailing list
> >Capwap@frascone.com
> > http://mail.frascone.com/mailman/listinfo/capwap
>
> _______________________________________________
> Capwap mailing list
> Capwap@frascone.com
> http://mail.frascone.com/mailman/listinfo/capwap
_______________________________________________
Capwap mailing list
Capwap@frascone.com
http://mail.frascone.com/mailman/listinfo/capwap
--=====================_227677352==.ALT-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 17:01:19 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25199 for ; Wed, 9 Mar 2005 17:01:15 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 451C22063D; Wed, 9 Mar 2005 17:01:13 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 870EF20644; Wed, 9 Mar 2005 17:01:08 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C1E822063D for ; Wed, 9 Mar 2005 17:00:49 -0500 (EST) Received: from aruba-server.arubanetworks.com (216-31-249-253.cust.telepacific.net [216.31.249.253]) by mail.frascone.com (Postfix) with SMTP id 9A2232062E for ; Wed, 9 Mar 2005 17:00:44 -0500 (EST) Received: from [10.3.9.229] ([10.3.9.229] unverified) by aruba-server.arubanetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Mar 2005 14:00:43 -0800 Message-ID: <422F7208.5030605@arubanetworks.com> From: Partha Narasimhan User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Vakulenko Cc: Dan Harkins , capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP References: <200503091912.j29JCHwh096319@homebrew.trpz.com> <6.2.1.2.0.20050309230427.045f1ac0@pop.mail.yahoo.com> In-Reply-To: <6.2.1.2.0.20050309230427.045f1ac0@pop.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Mar 2005 22:00:43.0077 (UTC) FILETIME=[705DB750:01C524F3] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 09 Mar 2005 14:00:40 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit The idea is to download code into the WTP and have it reboot itself with the downloaded code. At this point, the original vendor installed code on the WTP is no longer active and the WTP has been reborn with the new code. This does require the AC vendor to have worked with the specific WTPs that they want to support or interoperate and create an image for these individual boards. We are not suggesting that we abstract the hardware capabilities on the WTP and interoperate at that level dynamically. The AC vendors are responsible for the code that they download into the WTP and for the subsequent proper operation of that piece of hardware. This is why the interoperability onus now rests on the AC vendors. If they dont have an image ready for a specific WTP, then they dont interoperate with that WTP. Thanks partha Michael Vakulenko wrote: > At 09:12 PM 3/9/2005, Dan Harkins wrote: > >> On the contrary. If the CAPWAP protocol defines a full control plane >> and data frame encapsulation it will have to define standard APIs >> that need to be supported by all interoperable WTPs. > > > If we are referring to Application Programming Interface (API) here, I > disagree with your comment. > > None of the well-known and widely used protocols (IP, TCP, FTP, HTTP, > you name it) required definition of an API that have to go with the > protocol. The whole point of defining a protocol is to decouple > implementation from external interface. > >> If Partha's approach is taken then all that is defined is a discovery >> and download protocol. The WTC runs the downloaded image and that >> contains the >> (not-defined by CAPWAP) control and data frame protocols. > > > I'm afraid you are over-simplifying it. This downloaded image is just > a piece of object code for a specific processor instruction set, > right? This piece of object code was created by compiling it with a > specific compiler, linking it with appropriate libraries and storing > it in some kind of a file format (e.g. ELF). Now this file has to be > downloaded to the WTP memory and dynamically linked to the rest of the > software running on the WTP. Once this is done, this piece of code can > be finally activated and make calls to WTP API software, which in turn > will exercise the actual hardware. > > All this is before mentioning such insignificant things as programming > model (tasks, threads, semaphores, queues, memory management, etc.) > and development tools needed for such an endeavor. > > Sorry for the tutorial, but it's going to be much simpler define > CAPWAP protocol than deal with all these issues. > >> No we're not talking about Java. >> >> The practicalities of achieving interoperability are solely on >> implementation of the discovery and download protocol. It is simple and >> therefore acheiving interoperability would not be hard. > > > Agreed. But what does this buy to us? > >> The practicalities of achieving stability and predictable performance >> are borne by the AC vendors who will guarantee that the image they >> provide to a WTP is stable and has predictable performance. > > > I'm confused now. This statement defeats the (declared) motivation of > this discussion: "/...the interoperability problem can be > restated as a customer's need to find WTPs that interoperate with > his/her choice of AC. Or at a minimum, the WTPs need to follow and > interoperate with the AC rather than the other way around. " > > > /Thanks, > > -- Michael V. > www.WaveCompass.com > > > > >> Dan. >> >> On Wed, 09 Mar 2005 20:45:25 +0200 you wrote >> > Partha, >> > >> > I don't see how your suggestion makes things simpler. If CAPWAP would >> > follow your approach, this WG had to define standard APIs that >> needs to be >> > supported by all interoperable WTPs. These APIs will have to be quite >> > low-level and detailed to provide interface to 802.11 chipset, >> Ethernet >> > driver and operating system of the WTPs. >> > >> > Moreover, different WTP models may use different processor cores and >> > therefore firmware object code cannot be the same for all WTPs. (We >> are not >> > talking about Java here, are we?.. :-) ) >> > >> > The real complexity of what you have proposed is in fact higher than >> > traditional approach to protocol design, if you consider >> practicalities of >> > achieving interoperability, stability and predictable performance for >> > downloadable firmware. >> > >> > -- Michael V. >> > http://www.WaveCompass.com >> > >> > >> > At 06:58 PM 3/9/2005, Partha Narasimhan wrote: >> > >> > >The primary reason for the existence of the CAPWAP group is to solve >> > >an interoperability problem between ACs and WTPs from different >> > >vendors so that an end-user/customer has the choice of purchasing WTPs >> > >and ACs from different vendors. The existing marketplace is full of >> > >single-vendor solutions. To that extent, if an end-user is able to >> > >purchase a WTP from a vendor that is different than the vendor >> > >supplying the AC, but get them to interoperate with each other to >> > >create a functioning WLAN, then the end-user's objective is largely >> > >accomplished. >> > > >> > >Based on existing single-vendor WLAN solutions, it is obvious that the >> > >AC is where most of the control and management intelligence >> > >resides. It is not far from the truth to state the AC determines what >> > >functions are turned on at the WTPs and, hence, what features are >> > >available in the WLAN. Arguably, the interoperability problem can be >> > >restated as a customer's need to find WTPs that interoperate with >> > >his/her choice of AC. Or at a minimum, the WTPs need to follow and >> > >interoperate with the AC rather than the other way around. >> > > >> > >Interoperability can be achieved at multiple levels. In most of the >> > >current discussion on the CAPWAP mailing list, the primary assumption >> > >seems to be that interoperability requirement seems to be between the >> > >individual software that both the WTP and the AC ship with and/or boot >> > >up with. Once both the devices are up and running with their images, >> > >the WTPs discover one or more ACs and, assuming everything is set up >> > >right, one of the discovered ACs will configure and bring up the WTP >> > >as part of the customer's WLAN using a protocol that will be defined >> > >as part of the CAPWAP WG's work. >> > > >> > >Interoperability can also be achieved using a simpler mechanism where >> > >a WTP boots up, discovers one or more ACs to create an association >> > >with. As part of the discovery process, the WTP identifies itself >> > >(vendor ID, hardware version, software version, etc.). One of the >> > >discovered ACs can then instruct the WTP to download a firmware image >> > >that the WTP should boot itself with at the end of the download >> > >process. Upon booting itself with this downloaded image, the WTP runs >> > >a protocol, quite possibly proprietary to the AC vendor, contained in >> > >the downloaded image to create an association with an AC and get >> > >configured to be a member of the WLAN. An AC from one vendor might >> > >download an image to a WTP that is completely different than an AC >> > >from another vendor. This does solve the end-user's requirement of >> > >getting interoperability between WTPs and ACs from different >> > >vendors. The control protocol used to get the WTP to become a member >> > >of the WLAN controlled and managed by the AC is totally upto the AC >> > >vendor's choice. >> > > >> > >Essentially, the solution becomes a simple protocol for the WTP to >> > >discover one or more ACs, identify itself to the ACs, and download an >> > >image from the AC, if possible, that it will boot itself with - a >> > >secure download problem rather than a WLAN configuration problem from >> > >an interoperability perspective. This solves the CAPWAP problem of >> > >interoperability without requiring a full-fledged, new control >> > >protocol that all the WTP and AC vendors have to implement for >> > >interoperability. It is sufficient to implement the simpler secure >> > >download protocol to get to interoperability. This removes the >> > >necessity to negotiate capabilities (split MAC vs local MAC, one >> > >person's split may not suit another but we cannot have infinite >> > >permutations of a split, etc.) since the WTP assumes capabilities that >> > >are contained in the image that the AC vendor chooses to build for >> > >it. Another benefit of this approach is the extensibility of this >> > >simpler approach to future wireless technologies or extensions to >> > >existing technologies since these are folded into the downloaded image >> > >and hence are transparent to the secure download protocol itself. >> > > >> > >What are the issues with such a secure download protocol? This >> > >requires an AC to have a bootable image for every single WTP that the >> > >AC wants to interoperate with. Which could be a matter of >> > >differentiation for the AC vendors. If one vendor supports 2 models of >> > >WTPs, while another one decides to support 10, then the marketplace >> > >could choose if they like the feature set of the former enough that >> > >they dont mind the reduced set of interoperable WTPs or whether they >> > >like the greater interoperability of the latter AC. Secondly, we need >> > >a mechanism for the WTP and the AC, soon after the discovery process, >> > >to create a trust relationship between each other so that the WTP is >> > >sure it is not downloading code from a malicious entity masquerading >> > >as an AC and the AC is sure it is not supplying code to an entity >> > >masquerading as a WTP. >> > > >> > >The secure download approach shifts the burden of interoperability to >> > >the AC vendors and lowers the barrier for the WTP vendors that strive >> > >for interoperability. This shift is fine since the AC is the center of >> > >control and management for a WLAN and it is in the AC vendor's >> > >interests to get to wider interoperability, if they so chose to >> > >do. This is also aligned with the current market reality where the AC >> > >vendors' capabilities determine what features are available on the >> > >WLAN. The WTP vendors are required to implement a simpler protocol to >> > >get to interoperability with multiple AC vendors. The level of >> > >interoperability is always determined by individual choices by the >> > >vendors. For example, an AC that only supports split MAC may not >> > >interoperate with a WTP that only suppports the local MAC. Arguably, >> > >the interoperability achievable by the secure download approach is no >> > >worse than what is possible with a full-blown control protocol. Not to >> > >mention the simplicity of the protocol that the CAPWAP WG needs to >> > >work on. >> > > >> > >We intend to submit a proposal along these lines to the CAPWAP WG. It >> > >will involve a simple process as follows: >> > >- a WTP discovers one or more ACs, >> > >- the WTP identifies itself to the ACs that it discovered, >> > >- the WTP and one of the ACs create a mutual trust relationship, and >> > >- the WTP downloading an image from an AC. >> > >The details will be present in the draft that will follow soon. >> > > >> > >This approach is quite different from what has been discussed in the >> > >WG so far. It probably also has implications on the objectives >> > >draft. I would like to initiate some discussion on whether all the >> > >mandatory objectives as stated in the current objectives draft are >> > >still valid. I understand that the objectives were stated with a >> > >full-fledged, open and/or externally verifiable protocol in mind. If a >> > >certain set of objectives precludes such a simpler solution then we >> > >may need to re-visit and discuss that set of objectives. In other >> > >words, if a set of objectives as they currently stand are unnecessary >> > >for solving the problem that we started out to address, then we should >> > >discuss these now. >> > > >> > >Thanks >> > >partha >> > >_______________________________________________ >> > >Capwap mailing list >> > >Capwap@frascone.com >> > > http://mail.frascone.com/mailman/listinfo/capwap >> > >> > _______________________________________________ >> > Capwap mailing list >> > Capwap@frascone.com >> > http://mail.frascone.com/mailman/listinfo/capwap >> _______________________________________________ >> Capwap mailing list >> Capwap@frascone.com >> http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 17:12:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25909 for ; Wed, 9 Mar 2005 17:12:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 04E342064F; Wed, 9 Mar 2005 17:12:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C919D2063C; Wed, 9 Mar 2005 17:12:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D9FF32063D for ; Wed, 9 Mar 2005 17:11:26 -0500 (EST) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 689102063C for ; Wed, 9 Mar 2005 17:11:23 -0500 (EST) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j29M9AED015892 for ; Wed, 9 Mar 2005 17:09:10 -0500 (EST) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j29M8SED014648 for ; Wed, 9 Mar 2005 17:08:38 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: <5844A41F4E146044A2E8356C6328588008010718@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUk3F2MJagjChnDQ+eJjnGeQRKI7gAF4FBA From: "Sadot, Emek (Emek)" To: "Dan Harkins" , "Michael Vakulenko" Cc: "Partha Narasimhan" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 17:09:45 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Partha's proposal introduces a great advantage related to future enhancement either within the 802.11 realm or associated to other technologies (e.g. 802.16). Bear in mind that defining a signaling protocol with particular embedded identifiers/object will required extensive extensions to maintain interoperability for any new feature/technology. Although I assume we cherish the CAPWAP group do we really want it to be an ongoing process? Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins Sent: Wednesday, March 09, 2005 2:12 PM To: Michael Vakulenko Cc: Partha Narasimhan; capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP=20 On the contrary. If the CAPWAP protocol defines a full control plane and data frame encapsulation it will have to define standard APIs that need to be supported by all interoperable WTPs. If Partha's approach is taken then all that is defined is a discovery and download protocol. The WTC runs the downloaded image and that contains the (not-defined by CAPWAP) control and data frame protocols. No we're not talking about Java. The practicalities of achieving interoperability are solely on implementation of the discovery and download protocol. It is simple and therefore acheiving interoperability would not be hard. The practicalities of achieving stability and predictable performance are borne by the AC vendors who will guarantee that the image they provide to a WTP is stable and has predictable performance. Dan. On Wed, 09 Mar 2005 20:45:25 +0200 you wrote > Partha, >=20 > I don't see how your suggestion makes things simpler. If CAPWAP would=20 > follow your approach, this WG had to define standard APIs that needs=20 > to be supported by all interoperable WTPs. These APIs will have to be=20 > quite low-level and detailed to provide interface to 802.11 chipset,=20 > Ethernet driver and operating system of the WTPs. >=20 > Moreover, different WTP models may use different processor cores and=20 > therefore firmware object code cannot be the same for all WTPs. (We=20 > are not talking about Java here, are we?.. :-) ) >=20 > The real complexity of what you have proposed is in fact higher than=20 > traditional approach to protocol design, if you consider=20 > practicalities of achieving interoperability, stability and=20 > predictable performance for downloadable firmware. >=20 > -- Michael V. > http://www.WaveCompass.com >=20 >=20 > At 06:58 PM 3/9/2005, Partha Narasimhan wrote: >=20 > >The primary reason for the existence of the CAPWAP group is to solve=20 > >an interoperability problem between ACs and WTPs from different=20 > >vendors so that an end-user/customer has the choice of purchasing=20 > >WTPs and ACs from different vendors. The existing marketplace is full > >of single-vendor solutions. To that extent, if an end-user is able to > >purchase a WTP from a vendor that is different than the vendor=20 > >supplying the AC, but get them to interoperate with each other to=20 > >create a functioning WLAN, then the end-user's objective is largely=20 > >accomplished. > > > >Based on existing single-vendor WLAN solutions, it is obvious that=20 > >the AC is where most of the control and management intelligence=20 > >resides. It is not far from the truth to state the AC determines what > >functions are turned on at the WTPs and, hence, what features are=20 > >available in the WLAN. Arguably, the interoperability problem can be=20 > >restated as a customer's need to find WTPs that interoperate with=20 > >his/her choice of AC. Or at a minimum, the WTPs need to follow and=20 > >interoperate with the AC rather than the other way around. > > > >Interoperability can be achieved at multiple levels. In most of the=20 > >current discussion on the CAPWAP mailing list, the primary assumption > >seems to be that interoperability requirement seems to be between the > >individual software that both the WTP and the AC ship with and/or=20 > >boot up with. Once both the devices are up and running with their=20 > >images, the WTPs discover one or more ACs and, assuming everything is > >set up right, one of the discovered ACs will configure and bring up=20 > >the WTP as part of the customer's WLAN using a protocol that will be=20 > >defined as part of the CAPWAP WG's work. > > > >Interoperability can also be achieved using a simpler mechanism where > >a WTP boots up, discovers one or more ACs to create an association=20 > >with. As part of the discovery process, the WTP identifies itself=20 > >(vendor ID, hardware version, software version, etc.). One of the=20 > >discovered ACs can then instruct the WTP to download a firmware image > >that the WTP should boot itself with at the end of the download=20 > >process. Upon booting itself with this downloaded image, the WTP runs > >a protocol, quite possibly proprietary to the AC vendor, contained in > >the downloaded image to create an association with an AC and get=20 > >configured to be a member of the WLAN. An AC from one vendor might=20 > >download an image to a WTP that is completely different than an AC=20 > >from another vendor. This does solve the end-user's requirement of=20 > >getting interoperability between WTPs and ACs from different vendors. > >The control protocol used to get the WTP to become a member of the=20 > >WLAN controlled and managed by the AC is totally upto the AC vendor's > >choice. > > > >Essentially, the solution becomes a simple protocol for the WTP to=20 > >discover one or more ACs, identify itself to the ACs, and download an > >image from the AC, if possible, that it will boot itself with - a=20 > >secure download problem rather than a WLAN configuration problem from > >an interoperability perspective. This solves the CAPWAP problem of=20 > >interoperability without requiring a full-fledged, new control=20 > >protocol that all the WTP and AC vendors have to implement for=20 > >interoperability. It is sufficient to implement the simpler secure=20 > >download protocol to get to interoperability. This removes the=20 > >necessity to negotiate capabilities (split MAC vs local MAC, one=20 > >person's split may not suit another but we cannot have infinite=20 > >permutations of a split, etc.) since the WTP assumes capabilities=20 > >that are contained in the image that the AC vendor chooses to build=20 > >for it. Another benefit of this approach is the extensibility of this > >simpler approach to future wireless technologies or extensions to=20 > >existing technologies since these are folded into the downloaded=20 > >image and hence are transparent to the secure download protocol itself. > > > >What are the issues with such a secure download protocol? This=20 > >requires an AC to have a bootable image for every single WTP that the > >AC wants to interoperate with. Which could be a matter of=20 > >differentiation for the AC vendors. If one vendor supports 2 models=20 > >of WTPs, while another one decides to support 10, then the=20 > >marketplace could choose if they like the feature set of the former=20 > >enough that they dont mind the reduced set of interoperable WTPs or=20 > >whether they like the greater interoperability of the latter AC.=20 > >Secondly, we need a mechanism for the WTP and the AC, soon after the=20 > >discovery process, to create a trust relationship between each other=20 > >so that the WTP is sure it is not downloading code from a malicious=20 > >entity masquerading as an AC and the AC is sure it is not supplying=20 > >code to an entity masquerading as a WTP. > > > >The secure download approach shifts the burden of interoperability to > >the AC vendors and lowers the barrier for the WTP vendors that strive > >for interoperability. This shift is fine since the AC is the center=20 > >of control and management for a WLAN and it is in the AC vendor's=20 > >interests to get to wider interoperability, if they so chose to do.=20 > >This is also aligned with the current market reality where the AC=20 > >vendors' capabilities determine what features are available on the=20 > >WLAN. The WTP vendors are required to implement a simpler protocol to > >get to interoperability with multiple AC vendors. The level of=20 > >interoperability is always determined by individual choices by the=20 > >vendors. For example, an AC that only supports split MAC may not=20 > >interoperate with a WTP that only suppports the local MAC. Arguably,=20 > >the interoperability achievable by the secure download approach is no > >worse than what is possible with a full-blown control protocol. Not=20 > >to mention the simplicity of the protocol that the CAPWAP WG needs to > >work on. > > > >We intend to submit a proposal along these lines to the CAPWAP WG. It > >will involve a simple process as follows: > >- a WTP discovers one or more ACs, > >- the WTP identifies itself to the ACs that it discovered, > >- the WTP and one of the ACs create a mutual trust relationship, and > >- the WTP downloading an image from an AC. > >The details will be present in the draft that will follow soon. > > > >This approach is quite different from what has been discussed in the=20 > >WG so far. It probably also has implications on the objectives draft. > >I would like to initiate some discussion on whether all the mandatory > >objectives as stated in the current objectives draft are still valid. > >I understand that the objectives were stated with a full-fledged,=20 > >open and/or externally verifiable protocol in mind. If a certain set=20 > >of objectives precludes such a simpler solution then we may need to=20 > >re-visit and discuss that set of objectives. In other words, if a set > >of objectives as they currently stand are unnecessary for solving the > >problem that we started out to address, then we should discuss these=20 > >now. > > > >Thanks > >partha > >_______________________________________________ > >Capwap mailing list > >Capwap@frascone.com > >http://mail.frascone.com/mailman/listinfo/capwap >=20 > -- Michael Vakulenko > Phone: +972-54-776-2269 >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 17:20:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26491 for ; Wed, 9 Mar 2005 17:20:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6DA4320659; Wed, 9 Mar 2005 17:20:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22C1F20654; Wed, 9 Mar 2005 17:20:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DAB162064C for ; Wed, 9 Mar 2005 17:19:55 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 5A8F92063D for ; Wed, 9 Mar 2005 17:19:52 -0500 (EST) Message-ID: <02a301c524f6$42401d60$456015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Sadot, Emek (Emek)" , "Dan Harkins" , "Michael Vakulenko" Cc: "Partha Narasimhan" , References: <5844A41F4E146044A2E8356C6328588008010718@nj7460avexu2.global.avaya.com> Subject: Re: [Capwap] A simpler approach to CAPWAP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 14:20:45 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Whether or not we standardize a WTP control protocol or a code downloading protocol has nothing to do with whether CAPWAP is an ongoing process. When the CAPWAP charter is complete, the group can disband (this is what we did with SEND). Or not (other WGs like DNSEXT do this). It depends on what the WG members want to do and whether the IESG agrees. jak ----- Original Message ----- From: "Sadot, Emek (Emek)" To: "Dan Harkins" ; "Michael Vakulenko" Cc: "Partha Narasimhan" ; Sent: Wednesday, March 09, 2005 2:09 PM Subject: RE: [Capwap] A simpler approach to CAPWAP Partha's proposal introduces a great advantage related to future enhancement either within the 802.11 realm or associated to other technologies (e.g. 802.16). Bear in mind that defining a signaling protocol with particular embedded identifiers/object will required extensive extensions to maintain interoperability for any new feature/technology. Although I assume we cherish the CAPWAP group do we really want it to be an ongoing process? Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins Sent: Wednesday, March 09, 2005 2:12 PM To: Michael Vakulenko Cc: Partha Narasimhan; capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP On the contrary. If the CAPWAP protocol defines a full control plane and data frame encapsulation it will have to define standard APIs that need to be supported by all interoperable WTPs. If Partha's approach is taken then all that is defined is a discovery and download protocol. The WTC runs the downloaded image and that contains the (not-defined by CAPWAP) control and data frame protocols. No we're not talking about Java. The practicalities of achieving interoperability are solely on implementation of the discovery and download protocol. It is simple and therefore acheiving interoperability would not be hard. The practicalities of achieving stability and predictable performance are borne by the AC vendors who will guarantee that the image they provide to a WTP is stable and has predictable performance. Dan. On Wed, 09 Mar 2005 20:45:25 +0200 you wrote > Partha, > > I don't see how your suggestion makes things simpler. If CAPWAP would > follow your approach, this WG had to define standard APIs that needs > to be supported by all interoperable WTPs. These APIs will have to be > quite low-level and detailed to provide interface to 802.11 chipset, > Ethernet driver and operating system of the WTPs. > > Moreover, different WTP models may use different processor cores and > therefore firmware object code cannot be the same for all WTPs. (We > are not talking about Java here, are we?.. :-) ) > > The real complexity of what you have proposed is in fact higher than > traditional approach to protocol design, if you consider > practicalities of achieving interoperability, stability and > predictable performance for downloadable firmware. > > -- Michael V. > http://www.WaveCompass.com > > > At 06:58 PM 3/9/2005, Partha Narasimhan wrote: > > >The primary reason for the existence of the CAPWAP group is to solve > >an interoperability problem between ACs and WTPs from different > >vendors so that an end-user/customer has the choice of purchasing > >WTPs and ACs from different vendors. The existing marketplace is full > >of single-vendor solutions. To that extent, if an end-user is able to > >purchase a WTP from a vendor that is different than the vendor > >supplying the AC, but get them to interoperate with each other to > >create a functioning WLAN, then the end-user's objective is largely > >accomplished. > > > >Based on existing single-vendor WLAN solutions, it is obvious that > >the AC is where most of the control and management intelligence > >resides. It is not far from the truth to state the AC determines what > >functions are turned on at the WTPs and, hence, what features are > >available in the WLAN. Arguably, the interoperability problem can be > >restated as a customer's need to find WTPs that interoperate with > >his/her choice of AC. Or at a minimum, the WTPs need to follow and > >interoperate with the AC rather than the other way around. > > > >Interoperability can be achieved at multiple levels. In most of the > >current discussion on the CAPWAP mailing list, the primary assumption > >seems to be that interoperability requirement seems to be between the > >individual software that both the WTP and the AC ship with and/or > >boot up with. Once both the devices are up and running with their > >images, the WTPs discover one or more ACs and, assuming everything is > >set up right, one of the discovered ACs will configure and bring up > >the WTP as part of the customer's WLAN using a protocol that will be > >defined as part of the CAPWAP WG's work. > > > >Interoperability can also be achieved using a simpler mechanism where > >a WTP boots up, discovers one or more ACs to create an association > >with. As part of the discovery process, the WTP identifies itself > >(vendor ID, hardware version, software version, etc.). One of the > >discovered ACs can then instruct the WTP to download a firmware image > >that the WTP should boot itself with at the end of the download > >process. Upon booting itself with this downloaded image, the WTP runs > >a protocol, quite possibly proprietary to the AC vendor, contained in > >the downloaded image to create an association with an AC and get > >configured to be a member of the WLAN. An AC from one vendor might > >download an image to a WTP that is completely different than an AC > >from another vendor. This does solve the end-user's requirement of > >getting interoperability between WTPs and ACs from different vendors. > >The control protocol used to get the WTP to become a member of the > >WLAN controlled and managed by the AC is totally upto the AC vendor's > >choice. > > > >Essentially, the solution becomes a simple protocol for the WTP to > >discover one or more ACs, identify itself to the ACs, and download an > >image from the AC, if possible, that it will boot itself with - a > >secure download problem rather than a WLAN configuration problem from > >an interoperability perspective. This solves the CAPWAP problem of > >interoperability without requiring a full-fledged, new control > >protocol that all the WTP and AC vendors have to implement for > >interoperability. It is sufficient to implement the simpler secure > >download protocol to get to interoperability. This removes the > >necessity to negotiate capabilities (split MAC vs local MAC, one > >person's split may not suit another but we cannot have infinite > >permutations of a split, etc.) since the WTP assumes capabilities > >that are contained in the image that the AC vendor chooses to build > >for it. Another benefit of this approach is the extensibility of this > >simpler approach to future wireless technologies or extensions to > >existing technologies since these are folded into the downloaded > >image and hence are transparent to the secure download protocol itself. > > > >What are the issues with such a secure download protocol? This > >requires an AC to have a bootable image for every single WTP that the > >AC wants to interoperate with. Which could be a matter of > >differentiation for the AC vendors. If one vendor supports 2 models > >of WTPs, while another one decides to support 10, then the > >marketplace could choose if they like the feature set of the former > >enough that they dont mind the reduced set of interoperable WTPs or > >whether they like the greater interoperability of the latter AC. > >Secondly, we need a mechanism for the WTP and the AC, soon after the > >discovery process, to create a trust relationship between each other > >so that the WTP is sure it is not downloading code from a malicious > >entity masquerading as an AC and the AC is sure it is not supplying > >code to an entity masquerading as a WTP. > > > >The secure download approach shifts the burden of interoperability to > >the AC vendors and lowers the barrier for the WTP vendors that strive > >for interoperability. This shift is fine since the AC is the center > >of control and management for a WLAN and it is in the AC vendor's > >interests to get to wider interoperability, if they so chose to do. > >This is also aligned with the current market reality where the AC > >vendors' capabilities determine what features are available on the > >WLAN. The WTP vendors are required to implement a simpler protocol to > >get to interoperability with multiple AC vendors. The level of > >interoperability is always determined by individual choices by the > >vendors. For example, an AC that only supports split MAC may not > >interoperate with a WTP that only suppports the local MAC. Arguably, > >the interoperability achievable by the secure download approach is no > >worse than what is possible with a full-blown control protocol. Not > >to mention the simplicity of the protocol that the CAPWAP WG needs to > >work on. > > > >We intend to submit a proposal along these lines to the CAPWAP WG. It > >will involve a simple process as follows: > >- a WTP discovers one or more ACs, > >- the WTP identifies itself to the ACs that it discovered, > >- the WTP and one of the ACs create a mutual trust relationship, and > >- the WTP downloading an image from an AC. > >The details will be present in the draft that will follow soon. > > > >This approach is quite different from what has been discussed in the > >WG so far. It probably also has implications on the objectives draft. > >I would like to initiate some discussion on whether all the mandatory > >objectives as stated in the current objectives draft are still valid. > >I understand that the objectives were stated with a full-fledged, > >open and/or externally verifiable protocol in mind. If a certain set > >of objectives precludes such a simpler solution then we may need to > >re-visit and discuss that set of objectives. In other words, if a set > >of objectives as they currently stand are unnecessary for solving the > >problem that we started out to address, then we should discuss these > >now. > > > >Thanks > >partha > >_______________________________________________ > >Capwap mailing list > >Capwap@frascone.com > >http://mail.frascone.com/mailman/listinfo/capwap > > -- Michael Vakulenko > Phone: +972-54-776-2269 > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 17:25:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26938 for ; Wed, 9 Mar 2005 17:25:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B81FB20658; Wed, 9 Mar 2005 17:25:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F407B2064C; Wed, 9 Mar 2005 17:25:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61D2920654 for ; Wed, 9 Mar 2005 17:24:01 -0500 (EST) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by mail.frascone.com (Postfix) with SMTP id 3CD262063A for ; Wed, 9 Mar 2005 17:23:58 -0500 (EST) Received: from unknown (HELO MICHAELV-LT.wavecompass.com) (mvakulenko@212.179.88.120 with login) by smtp011.mail.yahoo.com with SMTP; 9 Mar 2005 22:23:56 -0000 Message-Id: <6.2.1.2.0.20050310000752.045f3d90@pop.mail.yahoo.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 To: Partha Narasimhan From: Michael Vakulenko Subject: Re: [Capwap] A simpler approach to CAPWAP Cc: Dan Harkins , Paul Lambert , capwap@frascone.com In-Reply-To: <422F5C75.9030905@arubanetworks.com> References: <200503091922.j29JMrY1096382@homebrew.trpz.com> <422F5C75.9030905@arubanetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 10 Mar 2005 00:15:21 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) At 10:28 PM 3/9/2005, Partha Narasimhan wrote: >To add to Dan's comments, if we look at the landscape of AC vendors today, >there is a non-trivial amount of feature differentiation that is offered >by them. To imagine that a CAPWAP proposal could create hooks to turn on >or off a union of this feature set is unthinkable. Unless we are willing >to spend lots and lots of time on it, we are limited to specifying a >CAPWAP feature set that would look more like the intersection of the >individual feature sets offered by all the AC vendors today - essentially, >the bare minimum. If the marketplace requires more than that bare minimum, >it is forced to go with a single-vendor solution. At which point all the >noble objectives that CAPWAP started out with would have been nullified >since an interoperable solution has not suit the end-users' needs. These are all very valid comments. It's indeed going to be very difficult to design a protocol allowing vendor differentiation. IMHO, non-commodity ACs will have to go with single vendor approach in any case. It's just the specific solution you are proposing is not practical, in my opinion. Thanks, -- Michael V. www.WaveCompass.com >With the proposed solution, the AC vendors choose the feature set that >would be present in a multi-vendor solution. I have to imagine that would >be more than the bare minimum that a CAPWAP protocol would standardize on. > >Thanks >partha > >Dan Harkins wrote: > >> Paul, >> >> I don't think it's designed to replace other control functionality. >>The point is that it is not necessary to standardize that control >>functionality. The control functionality (and how and where to split >>a MAC, for instance) is all contained in the code running on the AC >>and the code in the image the AC provides to the WTP. How the control >>plane and data encapsulation are defined is up to the AC vendor (who >>wrote the code for running on the AC and also the code in the image >>provided to the WTC) and not to the IETF. >> >> Let a Hundred Flowers Bloom! >> >> Dan. >> >>On Wed, 09 Mar 2005 11:14:39 PST you wrote >> >> >>>This 'simpler' approach would never work as propoposed to replace other >>>control functioanlity. >>> >>>A software upgrade mechanism might be desireable. This >>>upgrade process would never replace a fuller set of control protocols. >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On >>>>Behalf Of Partha Narasimhan >>>>Sent: Wednesday, March 09, 2005 11:06 AM >>>>To: Michael Vakulenko >>>>Cc: capwap@frascone.com >>>>Subject: RE: [Capwap] A simpler approach to CAPWAP >>>> >>>>Just to clarify.... >>>> >>>>This moves the onus of interoperability onto the AC vendors. They make >>>>images for a set of WTPs that they want to interoperate with. >>>The AC vendor may not have the desire or the bandwidth to make WTP >>>images. >>> >>>Unless the WTP are on standardized hardwar, how would a AC vendor build >>>an image? >>> >>> >>>>The WTP vendors just have to implement a protocol where they discover >>>>ACs, identify themselves, and have the ability to download an image and >>>>boot themselves with it. The original image on WTP could do other >>>>things (the WTP vendor's choice) with their installed images in an >>>>environment where they are unable to discover an AC. >>>>We are not calling for specifying how a WTP is built or with what >>>>components. Once it is built, every AC vendor that wants that >>>>particular model of WTP to work with needs to work with that WTP vendor >>>>and create their own version of a downloadable image for that board. >>>This is NOT the nature of open interoperable standards. A Company >>>should not have to work directly with every other vendor >>>to create interoperable systems. >>> >>>Paul >>>_______________________________________________ >>>Capwap mailing list >>>Capwap@frascone.com >>>http://mail.frascone.com/mailman/listinfo/capwap >>> >>> >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 17:25:28 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26976 for ; Wed, 9 Mar 2005 17:25:25 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A895520662; Wed, 9 Mar 2005 17:25:25 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61C6B2065F; Wed, 9 Mar 2005 17:25:17 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 513012063A for ; Wed, 9 Mar 2005 17:24:03 -0500 (EST) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by mail.frascone.com (Postfix) with SMTP id 029BE2064C for ; Wed, 9 Mar 2005 17:24:00 -0500 (EST) Received: from unknown (HELO MICHAELV-LT.wavecompass.com) (mvakulenko@212.179.88.120 with login) by smtp011.mail.yahoo.com with SMTP; 9 Mar 2005 22:23:58 -0000 Message-Id: <6.2.1.2.0.20050310001628.04d64490@pop.mail.yahoo.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 To: Partha Narasimhan From: Michael Vakulenko Subject: Re: [Capwap] A simpler approach to CAPWAP Cc: Dan Harkins , capwap@frascone.com In-Reply-To: <422F7208.5030605@arubanetworks.com> References: <200503091912.j29JCHwh096319@homebrew.trpz.com> <6.2.1.2.0.20050309230427.045f1ac0@pop.mail.yahoo.com> <422F7208.5030605@arubanetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 10 Mar 2005 00:22:10 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) At 12:00 AM 3/10/2005, Partha Narasimhan wrote: >The idea is to download code into the WTP and have it reboot itself with >the downloaded code. At this point, the original vendor installed code on >the WTP is no longer active and the WTP has been reborn with the new code. >This does require the AC vendor to have worked with the specific WTPs that >they want to support or interoperate and create an image for these >individual boards. We are not suggesting that we abstract the hardware >capabilities on the WTP and interoperate at that level dynamically. The AC >vendors are responsible for the code that they download into the WTP and >for the subsequent proper operation of that piece of hardware. How it's different from just having several WTP models on AC vendors's price list, as it happens today? What makes you believe that an AC vendor will assume responsibility for a piece of hardware bought on the street? -- Michael V. www.WaveCompass.com >This is why the interoperability onus now rests on the AC vendors. If they >dont have an image ready for a specific WTP, then they dont interoperate >with that WTP. > >Thanks >partha > >Michael Vakulenko wrote: > >>At 09:12 PM 3/9/2005, Dan Harkins wrote: >> >>> On the contrary. If the CAPWAP protocol defines a full control plane >>>and data frame encapsulation it will have to define standard APIs >>>that need to be supported by all interoperable WTPs. >> >> >>If we are referring to Application Programming Interface (API) here, I >>disagree with your comment. >> >>None of the well-known and widely used protocols (IP, TCP, FTP, HTTP, you >>name it) required definition of an API that have to go with the protocol. >>The whole point of defining a protocol is to decouple implementation from >>external interface. >> >>>If Partha's approach is taken then all that is defined is a discovery >>>and download protocol. The WTC runs the downloaded image and that contains the >>>(not-defined by CAPWAP) control and data frame protocols. >> >> >>I'm afraid you are over-simplifying it. This downloaded image is just a >>piece of object code for a specific processor instruction set, right? >>This piece of object code was created by compiling it with a specific >>compiler, linking it with appropriate libraries and storing it in some >>kind of a file format (e.g. ELF). Now this file has to be downloaded to >>the WTP memory and dynamically linked to the rest of the software running >>on the WTP. Once this is done, this piece of code can be finally >>activated and make calls to WTP API software, which in turn will exercise >>the actual hardware. >> >>All this is before mentioning such insignificant things as programming >>model (tasks, threads, semaphores, queues, memory management, etc.) and >>development tools needed for such an endeavor. >> >>Sorry for the tutorial, but it's going to be much simpler define CAPWAP >>protocol than deal with all these issues. >> >>> No we're not talking about Java. >>> >>> The practicalities of achieving interoperability are solely on >>>implementation of the discovery and download protocol. It is simple and >>>therefore acheiving interoperability would not be hard. >> >> >>Agreed. But what does this buy to us? >> >>>The practicalities of achieving stability and predictable performance >>>are borne by the AC vendors who will guarantee that the image they >>>provide to a WTP is stable and has predictable performance. >> >> >>I'm confused now. This statement defeats the (declared) motivation of >>this discussion: "/...the interoperability problem can be >>restated as a customer's need to find WTPs that interoperate with >>his/her choice of AC. Or at a minimum, the WTPs need to follow and >>interoperate with the AC rather than the other way around. " >> >> >>/Thanks, >> >>-- Michael V. >> www.WaveCompass.com >> >> >> >> >>> Dan. >>> >>>On Wed, 09 Mar 2005 20:45:25 +0200 you wrote >>> > Partha, >>> > >>> > I don't see how your suggestion makes things simpler. If CAPWAP would >>> > follow your approach, this WG had to define standard APIs that needs >>> to be >>> > supported by all interoperable WTPs. These APIs will have to be quite >>> > low-level and detailed to provide interface to 802.11 chipset, Ethernet >>> > driver and operating system of the WTPs. >>> > >>> > Moreover, different WTP models may use different processor cores and >>> > therefore firmware object code cannot be the same for all WTPs. (We >>> are not >>> > talking about Java here, are we?.. :-) ) >>> > >>> > The real complexity of what you have proposed is in fact higher than >>> > traditional approach to protocol design, if you consider >>> practicalities of >>> > achieving interoperability, stability and predictable performance for >>> > downloadable firmware. >>> > >>> > -- Michael V. >>> > http://www.WaveCompass.com >>> > >>> > >>> > At 06:58 PM 3/9/2005, Partha Narasimhan wrote: >>> > >>> > >The primary reason for the existence of the CAPWAP group is to solve >>> > >an interoperability problem between ACs and WTPs from different >>> > >vendors so that an end-user/customer has the choice of purchasing WTPs >>> > >and ACs from different vendors. The existing marketplace is full of >>> > >single-vendor solutions. To that extent, if an end-user is able to >>> > >purchase a WTP from a vendor that is different than the vendor >>> > >supplying the AC, but get them to interoperate with each other to >>> > >create a functioning WLAN, then the end-user's objective is largely >>> > >accomplished. >>> > > >>> > >Based on existing single-vendor WLAN solutions, it is obvious that the >>> > >AC is where most of the control and management intelligence >>> > >resides. It is not far from the truth to state the AC determines what >>> > >functions are turned on at the WTPs and, hence, what features are >>> > >available in the WLAN. Arguably, the interoperability problem can be >>> > >restated as a customer's need to find WTPs that interoperate with >>> > >his/her choice of AC. Or at a minimum, the WTPs need to follow and >>> > >interoperate with the AC rather than the other way around. >>> > > >>> > >Interoperability can be achieved at multiple levels. In most of the >>> > >current discussion on the CAPWAP mailing list, the primary assumption >>> > >seems to be that interoperability requirement seems to be between the >>> > >individual software that both the WTP and the AC ship with and/or boot >>> > >up with. Once both the devices are up and running with their images, >>> > >the WTPs discover one or more ACs and, assuming everything is set up >>> > >right, one of the discovered ACs will configure and bring up the WTP >>> > >as part of the customer's WLAN using a protocol that will be defined >>> > >as part of the CAPWAP WG's work. >>> > > >>> > >Interoperability can also be achieved using a simpler mechanism where >>> > >a WTP boots up, discovers one or more ACs to create an association >>> > >with. As part of the discovery process, the WTP identifies itself >>> > >(vendor ID, hardware version, software version, etc.). One of the >>> > >discovered ACs can then instruct the WTP to download a firmware image >>> > >that the WTP should boot itself with at the end of the download >>> > >process. Upon booting itself with this downloaded image, the WTP runs >>> > >a protocol, quite possibly proprietary to the AC vendor, contained in >>> > >the downloaded image to create an association with an AC and get >>> > >configured to be a member of the WLAN. An AC from one vendor might >>> > >download an image to a WTP that is completely different than an AC >>> > >from another vendor. This does solve the end-user's requirement of >>> > >getting interoperability between WTPs and ACs from different >>> > >vendors. The control protocol used to get the WTP to become a member >>> > >of the WLAN controlled and managed by the AC is totally upto the AC >>> > >vendor's choice. >>> > > >>> > >Essentially, the solution becomes a simple protocol for the WTP to >>> > >discover one or more ACs, identify itself to the ACs, and download an >>> > >image from the AC, if possible, that it will boot itself with - a >>> > >secure download problem rather than a WLAN configuration problem from >>> > >an interoperability perspective. This solves the CAPWAP problem of >>> > >interoperability without requiring a full-fledged, new control >>> > >protocol that all the WTP and AC vendors have to implement for >>> > >interoperability. It is sufficient to implement the simpler secure >>> > >download protocol to get to interoperability. This removes the >>> > >necessity to negotiate capabilities (split MAC vs local MAC, one >>> > >person's split may not suit another but we cannot have infinite >>> > >permutations of a split, etc.) since the WTP assumes capabilities that >>> > >are contained in the image that the AC vendor chooses to build for >>> > >it. Another benefit of this approach is the extensibility of this >>> > >simpler approach to future wireless technologies or extensions to >>> > >existing technologies since these are folded into the downloaded image >>> > >and hence are transparent to the secure download protocol itself. >>> > > >>> > >What are the issues with such a secure download protocol? This >>> > >requires an AC to have a bootable image for every single WTP that the >>> > >AC wants to interoperate with. Which could be a matter of >>> > >differentiation for the AC vendors. If one vendor supports 2 models of >>> > >WTPs, while another one decides to support 10, then the marketplace >>> > >could choose if they like the feature set of the former enough that >>> > >they dont mind the reduced set of interoperable WTPs or whether they >>> > >like the greater interoperability of the latter AC. Secondly, we need >>> > >a mechanism for the WTP and the AC, soon after the discovery process, >>> > >to create a trust relationship between each other so that the WTP is >>> > >sure it is not downloading code from a malicious entity masquerading >>> > >as an AC and the AC is sure it is not supplying code to an entity >>> > >masquerading as a WTP. >>> > > >>> > >The secure download approach shifts the burden of interoperability to >>> > >the AC vendors and lowers the barrier for the WTP vendors that strive >>> > >for interoperability. This shift is fine since the AC is the center of >>> > >control and management for a WLAN and it is in the AC vendor's >>> > >interests to get to wider interoperability, if they so chose to >>> > >do. This is also aligned with the current market reality where the AC >>> > >vendors' capabilities determine what features are available on the >>> > >WLAN. The WTP vendors are required to implement a simpler protocol to >>> > >get to interoperability with multiple AC vendors. The level of >>> > >interoperability is always determined by individual choices by the >>> > >vendors. For example, an AC that only supports split MAC may not >>> > >interoperate with a WTP that only suppports the local MAC. Arguably, >>> > >the interoperability achievable by the secure download approach is no >>> > >worse than what is possible with a full-blown control protocol. Not to >>> > >mention the simplicity of the protocol that the CAPWAP WG needs to >>> > >work on. >>> > > >>> > >We intend to submit a proposal along these lines to the CAPWAP WG. It >>> > >will involve a simple process as follows: >>> > >- a WTP discovers one or more ACs, >>> > >- the WTP identifies itself to the ACs that it discovered, >>> > >- the WTP and one of the ACs create a mutual trust relationship, and >>> > >- the WTP downloading an image from an AC. >>> > >The details will be present in the draft that will follow soon. >>> > > >>> > >This approach is quite different from what has been discussed in the >>> > >WG so far. It probably also has implications on the objectives >>> > >draft. I would like to initiate some discussion on whether all the >>> > >mandatory objectives as stated in the current objectives draft are >>> > >still valid. I understand that the objectives were stated with a >>> > >full-fledged, open and/or externally verifiable protocol in mind. If a >>> > >certain set of objectives precludes such a simpler solution then we >>> > >may need to re-visit and discuss that set of objectives. In other >>> > >words, if a set of objectives as they currently stand are unnecessary >>> > >for solving the problem that we started out to address, then we should >>> > >discuss these now. >>> > > >>> > >Thanks >>> > >partha >>> > >_______________________________________________ >>> > >Capwap mailing list >>> > >Capwap@frascone.com >>> > > http://mail.frascone.com/mailman/listinfo/capwap >>> > >>> > _______________________________________________ >>> > Capwap mailing list >>> > Capwap@frascone.com >>> > http://mail.frascone.com/mailman/listinfo/capwap >>>_______________________________________________ >>>Capwap mailing list >>>Capwap@frascone.com >>>http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 17:43:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28497 for ; Wed, 9 Mar 2005 17:43:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7FD6220642; Wed, 9 Mar 2005 17:43:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A93A2043B; Wed, 9 Mar 2005 17:43:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 637132043B for ; Wed, 9 Mar 2005 17:42:06 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 3765B1FC64 for ; Wed, 9 Mar 2005 17:42:03 -0500 (EST) Message-ID: <02ae01c524f9$5c360d30$456015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Dan Harkins" Cc: "Paul Lambert" , "Partha Narasimhan" , "Michael Vakulenko" , References: <200503092050.j29KoHIG096861@homebrew.trpz.com> Subject: Re: [Capwap] A simpler approach to CAPWAP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 14:42:56 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > Well it's a Chairman Mao quote so it might cause other problems for > them as well. > Actually, I think the exact quote is "Let a thousand flowers bloom!" See: http://www.newsarama.com/Thousand_Flowers_index.htm You're right about the disapproval, but I think it would have been bidirectional. > I fail to see the cost you are imagining. > Suppose a large wireless ISP decides to buy ACs from two or more vendors. Now, suppose the protocol, to say nothing of the split in MAC functions, is different between the different ACs. The WTPs might interoperate with a specific switch, but the wireless ISP must pay for personnel to learn each of the different protocols, including updates and training. When something goes wrong, the right person that knows the particular protocol must be located, and if they are on vacation, you are out of luck. Mistakes are more likely in configuration and maintenance if the protocols and MAC functions are different, since it becomes harder for people to remember the different configurations and parameter settings, and easier to make a mistake by inputting the settings for one protocol/AC to another. These are all problems with nonstandardized gear. Nonstandardized protocols just lead to vendor lock-in, which is no benefit to service providers. The cellular world went through this battle 10 years ago. The GSM and cdma1 networks had proprietary RAN protocols. The wireless operators in 3GPP insisted on having a standardized RAN protocol with standardized interfaces to reduce equipment cost, increase network maintainability (and thereby reduce OPEX), and simplify evolution of both the radio and RAN. The result of this is the standardized UMTS RAN protocols (RANAP, NSAP, NBAP). 3GPP2 took longer, but they also approved a standardized RAN protocol for cdma2K. I think the same arguments apply to CAPWAP. If I thought there were some technical advantage to keeping the protocol open, like, for example, open research issues, I'd certainly argue differently. But I believe there is enough experience in RAN protocol design of this sort from the cellular world, and I think the service providers really do want a standard. I'd hope that IETF is still willing to listen to service providers. jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 17:48:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28849 for ; Wed, 9 Mar 2005 17:48:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D12220659; Wed, 9 Mar 2005 17:48:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E878D20447; Wed, 9 Mar 2005 17:48:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8BB0820447 for ; Wed, 9 Mar 2005 17:47:40 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 4175B2043B for ; Wed, 9 Mar 2005 17:47:37 -0500 (EST) Message-ID: <02c501c524fa$23723b80$456015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Partha Narasimhan" , "Michael Vakulenko" Cc: "Dan Harkins" , "Paul Lambert" , References: <200503091922.j29JMrY1096382@homebrew.trpz.com> <422F5C75.9030905@arubanetworks.com> <6.2.1.2.0.20050310000752.045f3d90@pop.mail.yahoo.com> Subject: Re: [Capwap] A simpler approach to CAPWAP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 14:48:31 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > These are all very valid comments. It's indeed going to be very difficult > to design a protocol allowing vendor differentiation. IMHO, non-commodity > ACs will have to go with single vendor approach in any case. > I don't know that this is the case. In the UMTS world where the RAN protocols are standardized, the RAN vendors differentiate themselves based on their network managment systems. Many operators buy single vendor in order to get a particular set of network management features. Others (typically the more technically savvy) buy multivendor and roll their own network management software. If the protocol is standarized, the vendors will find other areas to distinguish their products. jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 17:57:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29414 for ; Wed, 9 Mar 2005 17:57:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1545D20665; Wed, 9 Mar 2005 17:57:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 060BF20467; Wed, 9 Mar 2005 17:57:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B4502062E for ; Wed, 9 Mar 2005 17:56:15 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mail.frascone.com (Postfix) with ESMTP id 2C2582043B for ; Wed, 9 Mar 2005 17:56:12 -0500 (EST) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j29MuAU14926 for ; Thu, 10 Mar 2005 00:56:10 +0200 (EET) X-Scanned: Thu, 10 Mar 2005 00:55:26 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j29MtQ7l027969 for ; Thu, 10 Mar 2005 00:55:26 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00lHvlW4; Thu, 10 Mar 2005 00:55:25 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j29MtMM05638 for ; Thu, 10 Mar 2005 00:55:22 +0200 (EET) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Mar 2005 16:55:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: Thread-Topic: A simpler approach to CAPWAP Thread-Index: AcUkyTkZeOJkvi+lQLCb7JYxtzARZAAHMXMwAAVCRCA= From: To: X-OriginalArrivalTime: 09 Mar 2005 22:55:20.0858 (UTC) FILETIME=[121367A0:01C524FB] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 14:55:20 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Gellert Dorothy (Nokia-ES/MtView)=20 Sent: Wednesday, March 09, 2005 12:41 PM To: 'ext Partha Narasimhan' Subject: RE: [Capwap] A simpler approach to CAPWAP Partha- I believe we have gone through an extensive market evaluation in our = last Charter with the taxonomy draft, and have created a charter that = was agreed upon that includes control. I don't see a reason to change = this. I also don't believe in the vendor id solution. It doesn't work from = the operator's perspective, since the operator has to individually = negotiate features from all vendors they support to create a homogenous = network. This is hardly interoperable. The benefits to the customer of = the network view was very well stated in taxonomy draft that was = reviewed and accepted by the IEEE and the IESG. This is one of our = basic requirements for the formation of this WG. We should also be complete in addressing all the AP functions in a BSS = to deliver a complete solution. =20 I also don't see a need to change the Objectives draft as it stands now, = as it meet the problem statement and represents the findings in the = taxonomy draft. While the architecture you describe is certainly an approach to this = problem, it doesn't meet the needs of this chartered WG. Dorothy -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On Behalf Of ext Partha Narasimhan Sent: Wednesday, March 09, 2005 8:59 AM To: capwap@frascone.com Subject: [Capwap] A simpler approach to CAPWAP The primary reason for the existence of the CAPWAP group is to solve an interoperability problem between ACs and WTPs from different vendors so that an end-user/customer has the choice of purchasing WTPs and ACs from different vendors. The existing marketplace is full of single-vendor solutions. To that extent, if an end-user is able to purchase a WTP from a vendor that is different than the vendor supplying the AC, but get them to interoperate with each other to create a functioning WLAN, then the end-user's objective is largely accomplished. Based on existing single-vendor WLAN solutions, it is obvious that the AC is where most of the control and management intelligence resides. It is not far from the truth to state the AC determines what functions are turned on at the WTPs and, hence, what features are available in the WLAN. Arguably, the interoperability problem can be restated as a customer's need to find WTPs that interoperate with his/her choice of AC. Or at a minimum, the WTPs need to follow and interoperate with the AC rather than the other way around.=20 Interoperability can be achieved at multiple levels. In most of the current discussion on the CAPWAP mailing list, the primary assumption seems to be that interoperability requirement seems to be between the individual software that both the WTP and the AC ship with and/or boot up with. Once both the devices are up and running with their images, the WTPs discover one or more ACs and, assuming everything is set up right, one of the discovered ACs will configure and bring up the WTP as part of the customer's WLAN using a protocol that will be defined as part of the CAPWAP WG's work. Interoperability can also be achieved using a simpler mechanism where a WTP boots up, discovers one or more ACs to create an association with. As part of the discovery process, the WTP identifies itself (vendor ID, hardware version, software version, etc.). One of the discovered ACs can then instruct the WTP to download a firmware image that the WTP should boot itself with at the end of the download process. Upon booting itself with this downloaded image, the WTP runs a protocol, quite possibly proprietary to the AC vendor, contained in the downloaded image to create an association with an AC and get configured to be a member of the WLAN. An AC from one vendor might download an image to a WTP that is completely different than an AC from another vendor. This does solve the end-user's requirement of getting interoperability between WTPs and ACs from different vendors. The control protocol used to get the WTP to become a member of the WLAN controlled and managed by the AC is totally upto the AC vendor's choice. Essentially, the solution becomes a simple protocol for the WTP to discover one or more ACs, identify itself to the ACs, and download an image from the AC, if possible, that it will boot itself with - a secure download problem rather than a WLAN configuration problem from an interoperability perspective. This solves the CAPWAP problem of interoperability without requiring a full-fledged, new control protocol that all the WTP and AC vendors have to implement for interoperability. It is sufficient to implement the simpler secure download protocol to get to interoperability. This removes the necessity to negotiate capabilities (split MAC vs local MAC, one person's split may not suit another but we cannot have infinite permutations of a split, etc.) since the WTP assumes capabilities that are contained in the image that the AC vendor chooses to build for it. Another benefit of this approach is the extensibility of this simpler approach to future wireless technologies or extensions to existing technologies since these are folded into the downloaded image and hence are transparent to the secure download protocol itself. What are the issues with such a secure download protocol? This requires an AC to have a bootable image for every single WTP that the AC wants to interoperate with. Which could be a matter of differentiation for the AC vendors. If one vendor supports 2 models of WTPs, while another one decides to support 10, then the marketplace could choose if they like the feature set of the former enough that they dont mind the reduced set of interoperable WTPs or whether they like the greater interoperability of the latter AC. Secondly, we need a mechanism for the WTP and the AC, soon after the discovery process, to create a trust relationship between each other so that the WTP is sure it is not downloading code from a malicious entity masquerading as an AC and the AC is sure it is not supplying code to an entity masquerading as a WTP.=20 The secure download approach shifts the burden of interoperability to the AC vendors and lowers the barrier for the WTP vendors that strive for interoperability. This shift is fine since the AC is the center of control and management for a WLAN and it is in the AC vendor's interests to get to wider interoperability, if they so chose to do. This is also aligned with the current market reality where the AC vendors' capabilities determine what features are available on the WLAN. The WTP vendors are required to implement a simpler protocol to get to interoperability with multiple AC vendors. The level of interoperability is always determined by individual choices by the vendors. For example, an AC that only supports split MAC may not interoperate with a WTP that only suppports the local MAC. Arguably, the interoperability achievable by the secure download approach is no worse than what is possible with a full-blown control protocol. Not to mention the simplicity of the protocol that the CAPWAP WG needs to work on. We intend to submit a proposal along these lines to the CAPWAP WG. It will involve a simple process as follows: - a WTP discovers one or more ACs, - the WTP identifies itself to the ACs that it discovered, - the WTP and one of the ACs create a mutual trust relationship, and - the WTP downloading an image from an AC. The details will be present in the draft that will follow soon. This approach is quite different from what has been discussed in the WG so far. It probably also has implications on the objectives draft. I would like to initiate some discussion on whether all the mandatory objectives as stated in the current objectives draft are still valid. I understand that the objectives were stated with a full-fledged, open and/or externally verifiable protocol in mind. If a certain set of objectives precludes such a simpler solution then we may need to re-visit and discuss that set of objectives. In other words, if a set of objectives as they currently stand are unnecessary for solving the problem that we started out to address, then we should discuss these now. Thanks partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 18:10:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00991 for ; Wed, 9 Mar 2005 18:10:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A39282043B; Wed, 9 Mar 2005 18:10:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 10FD22062E; Wed, 9 Mar 2005 18:10:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 427F620467 for ; Wed, 9 Mar 2005 18:09:28 -0500 (EST) Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by mail.frascone.com (Postfix) with SMTP id 0444E2043B for ; Wed, 9 Mar 2005 18:09:24 -0500 (EST) Received: from unknown (HELO MICHAELV-LT.wavecompass.com) (mvakulenko@212.179.88.120 with login) by smtp013.mail.yahoo.com with SMTP; 9 Mar 2005 23:09:21 -0000 Message-Id: <6.2.1.2.0.20050310005140.04d58180@pop.mail.yahoo.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 To: "James Kempf" From: Michael Vakulenko Subject: Re: [Capwap] A simpler approach to CAPWAP Cc: "Partha Narasimhan" , "Dan Harkins" , "Paul Lambert" , In-Reply-To: <02c501c524fa$23723b80$456015ac@dcml.docomolabsusa.com> References: <200503091922.j29JMrY1096382@homebrew.trpz.com> <422F5C75.9030905@arubanetworks.com> <6.2.1.2.0.20050310000752.045f3d90@pop.mail.yahoo.com> <02c501c524fa$23723b80$456015ac@dcml.docomolabsusa.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 10 Mar 2005 01:08:22 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) At 12:48 AM 3/10/2005, James Kempf wrote: > > These are all very valid comments. It's indeed going to be very difficult > > to design a protocol allowing vendor differentiation. IMHO, non-commodity > > ACs will have to go with single vendor approach in any case. > > > >I don't know that this is the case. In the UMTS world where the RAN >protocols are standardized, the RAN vendors differentiate themselves based >on their network managment systems. Many operators buy single vendor in >order to get a particular set of network management features. Others >(typically the more technically savvy) buy multivendor and roll their own >network management software. If the protocol is standarized, the vendors >will find other areas to distinguish their products. I'm glad you are bringing up cellular. This happen to be a good example. Yes, there are elaborate standards defined. For example for GSM there is Abis interface and protocols defined between BTS and BSC (cousins of WTP and AC respectively). However, reality is that BTS and BSC from different vendors are not quite working together. BTSes are usually operated with the same vendor BSC. And this is in very stable GSM environment, let alone cdma2000 and less stable new UMTS environment. Multi-vendor environments are common in the core network, but not at the RAN level. Thanks, -- Michael V. www.WaveCompass.com _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 18:18:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02242 for ; Wed, 9 Mar 2005 18:18:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EDEFA2063A; Wed, 9 Mar 2005 18:18:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 72C222043B; Wed, 9 Mar 2005 18:18:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 745C92043B for ; Wed, 9 Mar 2005 18:17:15 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id D354220419 for ; Wed, 9 Mar 2005 18:17:10 -0500 (EST) Message-ID: <02ed01c524fe$43afe060$456015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Michael Vakulenko" Cc: "Partha Narasimhan" , "Dan Harkins" , "Paul Lambert" , References: <200503091922.j29JMrY1096382@homebrew.trpz.com> <422F5C75.9030905@arubanetworks.com> <6.2.1.2.0.20050310000752.045f3d90@pop.mail.yahoo.com> <02c501c524fa$23723b80$456015ac@dcml.docomolabsusa.com> <6.2.1.2.0.20050310005140.04d58180@pop.mail.yahoo.com> Subject: Re: [Capwap] A simpler approach to CAPWAP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 15:18:03 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > I'm glad you are bringing up cellular. This happen to be a good example. > Yes, there are elaborate standards defined. For example for GSM there is > Abis interface and protocols defined between BTS and BSC (cousins of WTP > and AC respectively). However, reality is that BTS and BSC from different > vendors are not quite working together. BTSes are usually operated with the > same vendor BSC. And this is in very stable GSM environment, let alone > cdma2000 and less stable new UMTS environment. > Well, this might have been true for GSM, but its not true in UMTS. Our UMTS RAN is multivendor. jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 18:38:06 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03580 for ; Wed, 9 Mar 2005 18:38:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2EDF820648; Wed, 9 Mar 2005 18:38:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A493720467; Wed, 9 Mar 2005 18:38:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EE39E20467 for ; Wed, 9 Mar 2005 18:37:13 -0500 (EST) Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by mail.frascone.com (Postfix) with ESMTP id 1B1CD20460 for ; Wed, 9 Mar 2005 18:37:11 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUk+hXgNTVlh1GTQ3+0Rj2+AfqyRgABbKVQ From: "Victor Lin" To: "James Kempf" , "Partha Narasimhan" , "Michael Vakulenko" Cc: "Dan Harkins" , "Paul Lambert" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 15:37:06 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I agree with James. I think standard protocol enables different venders focus on different technologies. In CAPWAP case, AC venders can focus more on networking (security, mobility, management, etc.) while WTP venders can try to bring up the latest communication and other technologies (MIMO, special antenna, different form factor, etc.). This will give user more flexibility on picking the right products for their network. Of course, venders will put out "standard with vender enhancement" products which enable special features if you buy AC and WTP from the same vender. At the end, the market will decide which one wins. Victor -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of James Kempf Sent: Wednesday, March 09, 2005 2:49 PM To: Partha Narasimhan; Michael Vakulenko Cc: Dan Harkins; Paul Lambert; capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP > These are all very valid comments. It's indeed going to be very difficult > to design a protocol allowing vendor differentiation. IMHO, non-commodity > ACs will have to go with single vendor approach in any case. > I don't know that this is the case. In the UMTS world where the RAN protocols are standardized, the RAN vendors differentiate themselves based on their network managment systems. Many operators buy single vendor in order to get a particular set of network management features. Others (typically the more technically savvy) buy multivendor and roll their own network management software. If the protocol is standarized, the vendors will find other areas to distinguish their products. jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 18:52:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05386 for ; Wed, 9 Mar 2005 18:52:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E52A120648; Wed, 9 Mar 2005 18:52:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 283492051E; Wed, 9 Mar 2005 18:52:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA3DB2051E for ; Wed, 9 Mar 2005 18:51:52 -0500 (EST) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id E407D20467 for ; Wed, 9 Mar 2005 18:51:50 -0500 (EST) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j29NnZ2f097498; Wed, 9 Mar 2005 15:49:35 -0800 (PST) (envelope-from dharkins@trpz.com) Message-Id: <200503092349.j29NnZ2f097498@homebrew.trpz.com> To: Michael Vakulenko Cc: capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP In-Reply-To: Your message of "Wed, 09 Mar 2005 23:43:32 +0200." <6.2.1.2.0.20050309230427.045f1ac0@pop.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <97496.1110412175.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 09 Mar 2005 15:49:35 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Wed, 09 Mar 2005 23:43:32 +0200 you wrote > > >If Partha's approach is taken then all that is defined is a discovery and > >download protocol. The WTC runs the downloaded image and that contains the > >(not-defined by CAPWAP) control and data frame protocols. > > I'm afraid you are over-simplifying it. This downloaded image is just a > piece of object code for a specific processor instruction set, right? This > piece of object code was created by compiling it with a specific compiler, > linking it with appropriate libraries and storing it in some kind of a file > format (e.g. ELF). Now this file has to be downloaded to the WTP memory and > dynamically linked to the rest of the software running on the WTP. Once > this is done, this piece of code can be finally activated and make calls to > WTP API software, which in turn will exercise the actual hardware. > > All this is before mentioning such insignificant things as programming > model (tasks, threads, semaphores, queues, memory management, etc.) and > development tools needed for such an endeavor. > > Sorry for the tutorial, but it's going to be much simpler define CAPWAP > protocol than deal with all these issues. You should be sorry; don't do that again. Yes it's "object code". And it's compiled "with a specific compiler" and "appropriate libraries" and blah blah ELF blah. But you're viewing this as some runtime loadable module that is dynamically linked to something that runs the WTP. This image RUNS THE WTP. It is a brain transplant. It is not a runtime loadable module, it's more like the de-penguinator (http://www.daemonology.net/depenguinator). If you tell me what radio chipset you have in your AP, what ethernet chip you're using, what your memory and flash layout looks like, and what your bootloader is expecting in terms of where the executable image resides I will create an image that runs your AP that makes it look just like one of our's--- that is, it speaks our proprietary control and data plane encapsulation protocol and is managed by our switch. > > No we're not talking about Java. > > > > The practicalities of achieving interoperability are solely on > >implementation of the discovery and download protocol. It is simple and > >therefore acheiving interoperability would not be hard. > > Agreed. But what does this buy to us? It buys us commodity-priced APs that can be managed by a plethora of ACs, each of which can continue to differentiate itself from other ACs by producing new and different features. It buys us extensibility for the next wireless media that hasn't yet been standardized. With the other model you have to rev the spec for every addition. > >The practicalities of achieving stability and predictable performance are > >borne by the AC vendors who will guarantee that the image they provide to > >a WTP is stable and has predictable performance. > > I'm confused now. This statement defeats the (declared) motivation of this > discussion: "...the interoperability problem can be > restated as a customer's need to find WTPs that interoperate with > his/her choice of AC. Or at a minimum, the WTPs need to follow and > interoperate with the AC rather than the other way around. " I don't see anything in that quote that is in opposition to anything I've said. Part of your confusion, I think, is that you have several hard and pre-conceived notions and you're trying to fit everything I say into them. Dan. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Mar 9 19:43:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09353 for ; Wed, 9 Mar 2005 19:43:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F120720662; Wed, 9 Mar 2005 19:43:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 72AA72062E; Wed, 9 Mar 2005 19:43:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9FB5C2062E for ; Wed, 9 Mar 2005 19:42:39 -0500 (EST) Received: from toronto-mail.chantrynetworks.com (unknown [67.69.27.58]) by mail.frascone.com (Postfix) with ESMTP id 6E1C9205E6 for ; Wed, 9 Mar 2005 19:42:37 -0500 (EST) Received: from [192.168.5.206] (helo=wxp35) by toronto-mail.chantrynetworks.com with esmtpa (Exim 4.42) id 1D95gy-0002qj-7M; Wed, 09 Mar 2005 13:13:58 -0500 From: "Inderpreet Singh" To: "'James Kempf'" , "'Partha Narasimhan'" , Subject: RE: : Re: [Capwap] A simpler approach to CAPWAP Message-ID: <008e01c524d4$a5132850$c305a8c0@toronto.chantrynetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <01ce01c524d2$1ac705b0$456015ac@dcml.docomolabsusa.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-AV-Scan: This message has been scanned by Chantry Networks, Toronto using ClamAV X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 13:20:12 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable James, I agree that firmware download is a nice to have. I am trying to rationalize the work that might potentially go on in defining yet = another method of firmware download in the context of CAPWAP. How is the = firmware download problem different and unique in the case of WTPs vs. routers, switches, printers, or any other networking device? Partha - I think what you are proposing is substantially changing the = scope of the CAPWAP charter. What you are proposing would mean that our group should be called PWAP WG as the control aspect would then be totally sidelined and that would be totally proprietary. I am not sure if there = is value in "only" a firmware update protocol for WTPs and ACs. --- Inderpreet Singh -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On = Behalf Of James Kempf Sent: Wednesday, March 09, 2005 1:02 PM To: Partha Narasimhan; capwap@frascone.com Subject: **** SPAM **** 3.1: Re: [Capwap] A simpler approach to CAPWAP Partha, I believe having downloadable firmware is a highly desirable requirement = for CAPWAP, to ensure AC- WTP interoperability. However, I do not believe it is a replacement for having an interoperable protocol. From a managability standpoint, I'd = like to have a protocol that was standardized among AC vendors, not a bunch = of proprietary protocols that would all require different specialized management expertiese (which adds up to OPEX expense). Personally, I = don't think restricting CAPWAP goals just to downloadable firmware would = fufill the charter, but I'll let it up to the chairs to make the call. jak ----- Original Message -----=20 From: "Partha Narasimhan" To: Sent: Wednesday, March 09, 2005 8:58 AM Subject: [Capwap] A simpler approach to CAPWAP The primary reason for the existence of the CAPWAP group is to solve an interoperability problem between ACs and WTPs from different vendors so that an end-user/customer has the choice of purchasing WTPs and ACs from different vendors. The existing marketplace is full of single-vendor solutions. To that extent, if an end-user is able to purchase a WTP from a vendor that is different than the vendor supplying the AC, but get them to interoperate with each other to create a functioning WLAN, then the end-user's objective is largely accomplished. Based on existing single-vendor WLAN solutions, it is obvious that the AC is where most of the control and management intelligence resides. It is not far from the truth to state the AC determines what functions are turned on at the WTPs and, hence, what features are available in the WLAN. Arguably, the interoperability problem can be restated as a customer's need to find WTPs that interoperate with his/her choice of AC. Or at a minimum, the WTPs need to follow and interoperate with the AC rather than the other way around. Interoperability can be achieved at multiple levels. In most of the current discussion on the CAPWAP mailing list, the primary assumption seems to be that interoperability requirement seems to be between the individual software that both the WTP and the AC ship with and/or boot up with. Once both the devices are up and running with their images, the WTPs discover one or more ACs and, assuming everything is set up right, one of the discovered ACs will configure and bring up the WTP as part of the customer's WLAN using a protocol that will be defined as part of the CAPWAP WG's work. Interoperability can also be achieved using a simpler mechanism where a WTP boots up, discovers one or more ACs to create an association with. As part of the discovery process, the WTP identifies itself (vendor ID, hardware version, software version, etc.). One of the discovered ACs can then instruct the WTP to download a firmware image that the WTP should boot itself with at the end of the download process. Upon booting itself with this downloaded image, the WTP runs a protocol, quite possibly proprietary to the AC vendor, contained in the downloaded image to create an association with an AC and get configured to be a member of the WLAN. An AC from one vendor might download an image to a WTP that is completely different than an AC from another vendor. This does solve the end-user's requirement of getting interoperability between WTPs and ACs from different vendors. The control protocol used to get the WTP to become a member of the WLAN controlled and managed by the AC is totally upto the AC vendor's choice. Essentially, the solution becomes a simple protocol for the WTP to discover one or more ACs, identify itself to the ACs, and download an image from the AC, if possible, that it will boot itself with - a secure download problem rather than a WLAN configuration problem from an interoperability perspective. This solves the CAPWAP problem of interoperability without requiring a full-fledged, new control protocol that all the WTP and AC vendors have to implement for interoperability. It is sufficient to implement the simpler secure download protocol to get to interoperability. This removes the necessity to negotiate capabilities (split MAC vs local MAC, one person's split may not suit another but we cannot have infinite permutations of a split, etc.) since the WTP assumes capabilities that are contained in the image that the AC vendor chooses to build for it. Another benefit of this approach is the extensibility of this simpler approach to future wireless technologies or extensions to existing technologies since these are folded into the downloaded image and hence are transparent to the secure download protocol itself. What are the issues with such a secure download protocol? This requires an AC to have a bootable image for every single WTP that the AC wants to interoperate with. Which could be a matter of differentiation for the AC vendors. If one vendor supports 2 models of WTPs, while another one decides to support 10, then the marketplace could choose if they like the feature set of the former enough that they dont mind the reduced set of interoperable WTPs or whether they like the greater interoperability of the latter AC. Secondly, we need a mechanism for the WTP and the AC, soon after the discovery process, to create a trust relationship between each other so that the WTP is sure it is not downloading code from a malicious entity masquerading as an AC and the AC is sure it is not supplying code to an entity masquerading as a WTP. The secure download approach shifts the burden of interoperability to the AC vendors and lowers the barrier for the WTP vendors that strive for interoperability. This shift is fine since the AC is the center of control and management for a WLAN and it is in the AC vendor's interests to get to wider interoperability, if they so chose to do. This is also aligned with the current market reality where the AC vendors' capabilities determine what features are available on the WLAN. The WTP vendors are required to implement a simpler protocol to get to interoperability with multiple AC vendors. The level of interoperability is always determined by individual choices by the vendors. For example, an AC that only supports split MAC may not interoperate with a WTP that only suppports the local MAC. Arguably, the interoperability achievable by the secure download approach is no worse than what is possible with a full-blown control protocol. Not to mention the simplicity of the protocol that the CAPWAP WG needs to work on. We intend to submit a proposal along these lines to the CAPWAP WG. It will involve a simple process as follows: - a WTP discovers one or more ACs, - the WTP identifies itself to the ACs that it discovered, - the WTP and one of the ACs create a mutual trust relationship, and - the WTP downloading an image from an AC. The details will be present in the draft that will follow soon. This approach is quite different from what has been discussed in the WG so far. It probably also has implications on the objectives draft. I would like to initiate some discussion on whether all the mandatory objectives as stated in the current objectives draft are still valid. I understand that the objectives were stated with a full-fledged, open and/or externally verifiable protocol in mind. If a certain set of objectives precludes such a simpler solution then we may need to re-visit and discuss that set of objectives. In other words, if a set of objectives as they currently stand are unnecessary for solving the problem that we started out to address, then we should discuss these now. Thanks partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Mar 10 01:39:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15335 for ; Thu, 10 Mar 2005 01:39:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC95C20665; Thu, 10 Mar 2005 01:39:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 62CC920640; Thu, 10 Mar 2005 01:39:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E31A720640 for ; Thu, 10 Mar 2005 01:38:10 -0500 (EST) Received: from sinett.com (63-197-255-158.ded.pacbell.net [63.197.255.158]) by mail.frascone.com (Postfix) with ESMTP id D55AC2063D for ; Thu, 10 Mar 2005 01:38:08 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUkyTkZeOJkvi+lQLCb7JYxtzARZAAHMXMwAAVCRCAAD3K+QA== From: "Vishwas Manral" To: , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Wed, 9 Mar 2005 22:38:07 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Partha/ Dorothy, > I also don't believe in the vendor id solution. It doesn't work from > the operator's perspective, since the operator has to individually=20 > negotiate features from all vendors they support to create a homogenous=20 > network. I do not agree with this comment, wouldn't the same be required in CAPWAP protocol too. I think this is done even in standard protocols (IS-IS is an example) where a vendor-id is specified in the proprietary TLV's used by vendor to do different proprietery interesting stuff. The protocol details of negotiation are much simpler. In my view the discussion is veering towards whether standard control mechanism can allow vendors to differentiate and the time it takes to standardize the mechanisms. Partha, is that right? Thanks, Vishwas -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dorothy.Gellert@nokia.com Sent: Thursday, March 10, 2005 4:25 AM To: capwap@frascone.com Subject: RE: [Capwap] A simpler approach to CAPWAP -----Original Message----- From: Gellert Dorothy (Nokia-ES/MtView)=20 Sent: Wednesday, March 09, 2005 12:41 PM To: 'ext Partha Narasimhan' Subject: RE: [Capwap] A simpler approach to CAPWAP Partha- I believe we have gone through an extensive market evaluation in our last Charter with the taxonomy draft, and have created a charter that was agreed upon that includes control. I don't see a reason to change this. I also don't believe in the vendor id solution. It doesn't work from the operator's perspective, since the operator has to individually negotiate features from all vendors they support to create a homogenous network. This is hardly interoperable. The benefits to the customer of the network view was very well stated in taxonomy draft that was reviewed and accepted by the IEEE and the IESG. This is one of our basic requirements for the formation of this WG. We should also be complete in addressing all the AP functions in a BSS to deliver a complete solution. =20 I also don't see a need to change the Objectives draft as it stands now, as it meet the problem statement and represents the findings in the taxonomy draft. While the architecture you describe is certainly an approach to this problem, it doesn't meet the needs of this chartered WG. Dorothy -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On Behalf Of ext Partha Narasimhan Sent: Wednesday, March 09, 2005 8:59 AM To: capwap@frascone.com Subject: [Capwap] A simpler approach to CAPWAP The primary reason for the existence of the CAPWAP group is to solve an interoperability problem between ACs and WTPs from different vendors so that an end-user/customer has the choice of purchasing WTPs and ACs from different vendors. The existing marketplace is full of single-vendor solutions. To that extent, if an end-user is able to purchase a WTP from a vendor that is different than the vendor supplying the AC, but get them to interoperate with each other to create a functioning WLAN, then the end-user's objective is largely accomplished. Based on existing single-vendor WLAN solutions, it is obvious that the AC is where most of the control and management intelligence resides. It is not far from the truth to state the AC determines what functions are turned on at the WTPs and, hence, what features are available in the WLAN. Arguably, the interoperability problem can be restated as a customer's need to find WTPs that interoperate with his/her choice of AC. Or at a minimum, the WTPs need to follow and interoperate with the AC rather than the other way around.=20 Interoperability can be achieved at multiple levels. In most of the current discussion on the CAPWAP mailing list, the primary assumption seems to be that interoperability requirement seems to be between the individual software that both the WTP and the AC ship with and/or boot up with. Once both the devices are up and running with their images, the WTPs discover one or more ACs and, assuming everything is set up right, one of the discovered ACs will configure and bring up the WTP as part of the customer's WLAN using a protocol that will be defined as part of the CAPWAP WG's work. Interoperability can also be achieved using a simpler mechanism where a WTP boots up, discovers one or more ACs to create an association with. As part of the discovery process, the WTP identifies itself (vendor ID, hardware version, software version, etc.). One of the discovered ACs can then instruct the WTP to download a firmware image that the WTP should boot itself with at the end of the download process. Upon booting itself with this downloaded image, the WTP runs a protocol, quite possibly proprietary to the AC vendor, contained in the downloaded image to create an association with an AC and get configured to be a member of the WLAN. An AC from one vendor might download an image to a WTP that is completely different than an AC from another vendor. This does solve the end-user's requirement of getting interoperability between WTPs and ACs from different vendors. The control protocol used to get the WTP to become a member of the WLAN controlled and managed by the AC is totally upto the AC vendor's choice. Essentially, the solution becomes a simple protocol for the WTP to discover one or more ACs, identify itself to the ACs, and download an image from the AC, if possible, that it will boot itself with - a secure download problem rather than a WLAN configuration problem from an interoperability perspective. This solves the CAPWAP problem of interoperability without requiring a full-fledged, new control protocol that all the WTP and AC vendors have to implement for interoperability. It is sufficient to implement the simpler secure download protocol to get to interoperability. This removes the necessity to negotiate capabilities (split MAC vs local MAC, one person's split may not suit another but we cannot have infinite permutations of a split, etc.) since the WTP assumes capabilities that are contained in the image that the AC vendor chooses to build for it. Another benefit of this approach is the extensibility of this simpler approach to future wireless technologies or extensions to existing technologies since these are folded into the downloaded image and hence are transparent to the secure download protocol itself. What are the issues with such a secure download protocol? This requires an AC to have a bootable image for every single WTP that the AC wants to interoperate with. Which could be a matter of differentiation for the AC vendors. If one vendor supports 2 models of WTPs, while another one decides to support 10, then the marketplace could choose if they like the feature set of the former enough that they dont mind the reduced set of interoperable WTPs or whether they like the greater interoperability of the latter AC. Secondly, we need a mechanism for the WTP and the AC, soon after the discovery process, to create a trust relationship between each other so that the WTP is sure it is not downloading code from a malicious entity masquerading as an AC and the AC is sure it is not supplying code to an entity masquerading as a WTP.=20 The secure download approach shifts the burden of interoperability to the AC vendors and lowers the barrier for the WTP vendors that strive for interoperability. This shift is fine since the AC is the center of control and management for a WLAN and it is in the AC vendor's interests to get to wider interoperability, if they so chose to do. This is also aligned with the current market reality where the AC vendors' capabilities determine what features are available on the WLAN. The WTP vendors are required to implement a simpler protocol to get to interoperability with multiple AC vendors. The level of interoperability is always determined by individual choices by the vendors. For example, an AC that only supports split MAC may not interoperate with a WTP that only suppports the local MAC. Arguably, the interoperability achievable by the secure download approach is no worse than what is possible with a full-blown control protocol. Not to mention the simplicity of the protocol that the CAPWAP WG needs to work on. We intend to submit a proposal along these lines to the CAPWAP WG. It will involve a simple process as follows: - a WTP discovers one or more ACs, - the WTP identifies itself to the ACs that it discovered, - the WTP and one of the ACs create a mutual trust relationship, and - the WTP downloading an image from an AC. The details will be present in the draft that will follow soon. This approach is quite different from what has been discussed in the WG so far. It probably also has implications on the objectives draft. I would like to initiate some discussion on whether all the mandatory objectives as stated in the current objectives draft are still valid. I understand that the objectives were stated with a full-fledged, open and/or externally verifiable protocol in mind. If a certain set of objectives precludes such a simpler solution then we may need to re-visit and discuss that set of objectives. In other words, if a set of objectives as they currently stand are unnecessary for solving the problem that we started out to address, then we should discuss these now. Thanks Partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Mar 10 22:52:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12015 for ; Thu, 10 Mar 2005 22:52:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 85F3020615; Thu, 10 Mar 2005 22:52:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B460520606; Thu, 10 Mar 2005 22:52:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B409F20606 for ; Thu, 10 Mar 2005 22:51:56 -0500 (EST) Received: from aruba-server.arubanetworks.com (216-31-249-252.cust.telepacific.net [216.31.249.252]) by mail.frascone.com (Postfix) with SMTP id 0024620604 for ; Thu, 10 Mar 2005 22:51:53 -0500 (EST) Received: from [10.3.9.229] ([10.3.9.229] unverified) by aruba-server.arubanetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Mar 2005 19:51:51 -0800 Message-ID: <423115D4.7040800@arubanetworks.com> From: Partha Narasimhan User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dorothy.Gellert@nokia.com Cc: capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Mar 2005 03:51:51.0337 (UTC) FILETIME=[A870D190:01C525ED] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 10 Mar 2005 19:51:48 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dorothy Thanks for your comments. Though I am not sure I am in complete agreement with all of them. The intent of my email and the draft that we will be submitting shortly to the WG is not to say that we do not need a control protocol. The disagreement that we have with the current state of the discussion in the WG on the objectives draft and the two proposals out there is that they seem geared towards something that is inherently more complex than what is required to solve the interoperability problem. We have already had lots of discussion in both the mailing list and in the CAPWAP session at the IETF on limiting the number of possibilities in the capabilities negotiation. If we take a split MAC architecture, for example, it would boil down to the IETF (or the IEEE) dictating how the MAC should be split because of the need to keep things simple. The solution we are proposing would simplify things significantly without restricting innovation on either side. There are a bunch of features that one or more of the AC vendors support in their single-vendor solutions that are not being negotiated in the control protocol in the interests of bounding the problem. Let us take the example of a WTP's ability to support multiple BSSIDs on the same radio. If we have no mechanism to negotiate this capability using the control protocol, then the only safe assumption is that the WTP does not possess this capability. We are either forced to increase the scope of the capabilities negotiation or restrict the feature set that is possible in a multi-vendor WLAN. What we are proposing will enable complete multi-vendor solutions that the marketplace desires and chooses - only it shifts that onus onto the AC vendors that want to interoperate with one or more WTPs and requiring the WTP vendors to implement a simple control protocol. Even from an service provider's point of view, this would appear to be a better solution since the responsibility of bringing up the network and maintaining it rests on the shoulders of the AC vendor, quite possibly, preventing finger pointing between the AC and WTP vendors in the case of problems. With a complex control protocol, we are forced with two choices: - to have a set of negotiable capabilities at either end that cover the union of the feature sets across all the AC vendors, which, based on the comments at the meeting, no one is in favor of, or - standardize on a set that looks more like the intersection of the feature sets, which seriously lowers the value of a multi-vendor deployment. In my mind, neither one of these choices seem acceptable. The motivation for simplifying the protocol came as a result of an exercise to scope out the complexity of a control protocol that guarantees true interoperability while not stifling innovation on either the WTP or the AC side of the equation. Not to mention the need to keep this control protocol in sync with whatever is coming down the pipeline from current and future standardization work at various bodies. I am surprised by your conclusion that the objectives draft is fine the way it is. One of the goals of reviewing the objectives draft is to ensure that it is not drawn up in a way that prevents a certain class of solutions that do solve the problem that we are setting out to solve from being considered because the objectives are more targeted for a different class of solutions. After all, this is the period in which the objectives draft is meant to go through such a review process. Thanks partha Dorothy.Gellert@nokia.com wrote: >-----Original Message----- >From: Gellert Dorothy (Nokia-ES/MtView) >Sent: Wednesday, March 09, 2005 12:41 PM >To: 'ext Partha Narasimhan' >Subject: RE: [Capwap] A simpler approach to CAPWAP > > >Partha- > >I believe we have gone through an extensive market evaluation in our last Charter with the taxonomy draft, and have created a charter that was agreed upon that includes control. I don't see a reason to change this. > >I also don't believe in the vendor id solution. It doesn't work from the operator's perspective, since the operator has to individually negotiate features from all vendors they support to create a homogenous network. This is hardly interoperable. The benefits to the customer of the network view was very well stated in taxonomy draft that was reviewed and accepted by the IEEE and the IESG. This is one of our basic requirements for the formation of this WG. > >We should also be complete in addressing all the AP functions in a BSS to deliver a complete solution. > >I also don't see a need to change the Objectives draft as it stands now, as it meet the problem statement and represents the findings in the taxonomy draft. > >While the architecture you describe is certainly an approach to this problem, it doesn't meet the needs of this chartered WG. > >Dorothy > > > > >-----Original Message----- >From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com]On >Behalf Of ext Partha Narasimhan >Sent: Wednesday, March 09, 2005 8:59 AM >To: capwap@frascone.com >Subject: [Capwap] A simpler approach to CAPWAP > > > >The primary reason for the existence of the CAPWAP group is to solve >an interoperability problem between ACs and WTPs from different >vendors so that an end-user/customer has the choice of purchasing WTPs >and ACs from different vendors. The existing marketplace is full of >single-vendor solutions. To that extent, if an end-user is able to >purchase a WTP from a vendor that is different than the vendor >supplying the AC, but get them to interoperate with each other to >create a functioning WLAN, then the end-user's objective is largely >accomplished. > >Based on existing single-vendor WLAN solutions, it is obvious that the >AC is where most of the control and management intelligence >resides. It is not far from the truth to state the AC determines what >functions are turned on at the WTPs and, hence, what features are >available in the WLAN. Arguably, the interoperability problem can be >restated as a customer's need to find WTPs that interoperate with >his/her choice of AC. Or at a minimum, the WTPs need to follow and >interoperate with the AC rather than the other way around. > >Interoperability can be achieved at multiple levels. In most of the >current discussion on the CAPWAP mailing list, the primary assumption >seems to be that interoperability requirement seems to be between the >individual software that both the WTP and the AC ship with and/or boot >up with. Once both the devices are up and running with their images, >the WTPs discover one or more ACs and, assuming everything is set up >right, one of the discovered ACs will configure and bring up the WTP >as part of the customer's WLAN using a protocol that will be defined >as part of the CAPWAP WG's work. > >Interoperability can also be achieved using a simpler mechanism where >a WTP boots up, discovers one or more ACs to create an association >with. As part of the discovery process, the WTP identifies itself >(vendor ID, hardware version, software version, etc.). One of the >discovered ACs can then instruct the WTP to download a firmware image >that the WTP should boot itself with at the end of the download >process. Upon booting itself with this downloaded image, the WTP runs >a protocol, quite possibly proprietary to the AC vendor, contained in >the downloaded image to create an association with an AC and get >configured to be a member of the WLAN. An AC from one vendor might >download an image to a WTP that is completely different than an AC >from another vendor. This does solve the end-user's requirement of >getting interoperability between WTPs and ACs from different >vendors. The control protocol used to get the WTP to become a member >of the WLAN controlled and managed by the AC is totally upto the AC >vendor's choice. > >Essentially, the solution becomes a simple protocol for the WTP to >discover one or more ACs, identify itself to the ACs, and download an >image from the AC, if possible, that it will boot itself with - a >secure download problem rather than a WLAN configuration problem from >an interoperability perspective. This solves the CAPWAP problem of >interoperability without requiring a full-fledged, new control >protocol that all the WTP and AC vendors have to implement for >interoperability. It is sufficient to implement the simpler secure >download protocol to get to interoperability. This removes the >necessity to negotiate capabilities (split MAC vs local MAC, one >person's split may not suit another but we cannot have infinite >permutations of a split, etc.) since the WTP assumes capabilities that >are contained in the image that the AC vendor chooses to build for >it. Another benefit of this approach is the extensibility of this >simpler approach to future wireless technologies or extensions to >existing technologies since these are folded into the downloaded image >and hence are transparent to the secure download protocol itself. > >What are the issues with such a secure download protocol? This >requires an AC to have a bootable image for every single WTP that the >AC wants to interoperate with. Which could be a matter of >differentiation for the AC vendors. If one vendor supports 2 models of >WTPs, while another one decides to support 10, then the marketplace >could choose if they like the feature set of the former enough that >they dont mind the reduced set of interoperable WTPs or whether they >like the greater interoperability of the latter AC. Secondly, we need >a mechanism for the WTP and the AC, soon after the discovery process, >to create a trust relationship between each other so that the WTP is >sure it is not downloading code from a malicious entity masquerading >as an AC and the AC is sure it is not supplying code to an entity >masquerading as a WTP. > >The secure download approach shifts the burden of interoperability to >the AC vendors and lowers the barrier for the WTP vendors that strive >for interoperability. This shift is fine since the AC is the center of >control and management for a WLAN and it is in the AC vendor's >interests to get to wider interoperability, if they so chose to >do. This is also aligned with the current market reality where the AC >vendors' capabilities determine what features are available on the >WLAN. The WTP vendors are required to implement a simpler protocol to >get to interoperability with multiple AC vendors. The level of >interoperability is always determined by individual choices by the >vendors. For example, an AC that only supports split MAC may not >interoperate with a WTP that only suppports the local MAC. Arguably, >the interoperability achievable by the secure download approach is no >worse than what is possible with a full-blown control protocol. Not to >mention the simplicity of the protocol that the CAPWAP WG needs to >work on. > >We intend to submit a proposal along these lines to the CAPWAP WG. It >will involve a simple process as follows: >- a WTP discovers one or more ACs, >- the WTP identifies itself to the ACs that it discovered, >- the WTP and one of the ACs create a mutual trust relationship, and >- the WTP downloading an image from an AC. >The details will be present in the draft that will follow soon. > >This approach is quite different from what has been discussed in the >WG so far. It probably also has implications on the objectives >draft. I would like to initiate some discussion on whether all the >mandatory objectives as stated in the current objectives draft are >still valid. I understand that the objectives were stated with a >full-fledged, open and/or externally verifiable protocol in mind. If a >certain set of objectives precludes such a simpler solution then we >may need to re-visit and discuss that set of objectives. In other >words, if a set of objectives as they currently stand are unnecessary >for solving the problem that we started out to address, then we should >discuss these now. > >Thanks >partha >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Mar 10 23:23:06 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14373 for ; Thu, 10 Mar 2005 23:23:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 006C620390; Thu, 10 Mar 2005 23:23:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A1F902031A; Thu, 10 Mar 2005 23:23:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7EB362031A for ; Thu, 10 Mar 2005 23:22:21 -0500 (EST) Received: from aruba-server.arubanetworks.com (216-31-249-252.cust.telepacific.net [216.31.249.252]) by mail.frascone.com (Postfix) with SMTP id A0CA32024C for ; Thu, 10 Mar 2005 23:22:19 -0500 (EST) Received: from [10.3.9.229] ([10.3.9.229] unverified) by aruba-server.arubanetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 10 Mar 2005 20:22:17 -0800 Message-ID: <42311CF6.9070802@arubanetworks.com> From: Partha Narasimhan User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vishwas Manral Cc: Dorothy.Gellert@nokia.com, capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Mar 2005 04:22:17.0474 (UTC) FILETIME=[E8E73620:01C525F1] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 10 Mar 2005 20:22:14 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Vishwas Manral wrote: > >In my view the discussion is veering towards whether standard control >mechanism can allow vendors to differentiate and the time it takes to >standardize the mechanisms. Partha, is that right? > > Yes. I have doubts over the possibility that a multi-vendor solution based on a complex control protocol (assuming that the extremely cost-conscious WTP vendors will implement their end of the bargain) could offer at least as good a feature set as many of the current single-vendor solutions do. And we all know that these single-vendor feature sets are moving targets. Thanks partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 11:09:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08710 for ; Fri, 11 Mar 2005 11:09:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4E22A20483; Fri, 11 Mar 2005 11:09:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A5D182041A; Fri, 11 Mar 2005 11:09:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7CF302041A for ; Fri, 11 Mar 2005 11:08:16 -0500 (EST) Received: from AIREMAIL.airespace.com (mail.airespace.com [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 95D2420399 for ; Fri, 11 Mar 2005 11:08:13 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Capwap] A simpler approach to CAPWAP Message-ID: <526F1C0D08561F4BB79022CB938A068B44FB74@AIREMAIL.airespace.com> Thread-Topic: Re: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUkyTkZeOJkvi+lQLCb7JYxtzARZAAHMXMwAAVCRCAAD3K+QAAo5aEAABzO5FAAAOyX4AAAPQgA From: "Pat R. Calhoun" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 08:08:03 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Well, I must admit that I was a little surprised about a proposal to create a non-standard. I agree with James and others that the CAPWAP WG must really create a complete protocol, one that is well documented, and is available for the network operators to use during the troubleshooting process. Seriously, what exactly is being proposed here? We already have several vendors with various protocols - the only difference is to allow a brain transplant of WTPs. As an aside, I recollect ruling this out of the problem statement very early on, so this whole discussion appears to be out of scope. As an AC vendor, the last thing that I really want to do is to have to have a staff of people that have to understand the various WTP HW architectures, not to mention the MACs which they all use, who spend their time porting their code to different HW. Seriously, what's the advantage to the AC vendor? It's a huge cost burden, and it really doesn't solve the end problem. Sure, I can hear the "market advantage of supporting more WTPs", but let's be fair here, we also have to provide a solution that allows companies to be fiscally responsible. You can imagine the scenario where a WTP vendor creates some significant value, but is unable to get the most popular AC vendor to want to support their platform - so this proposal actually stifles innovation, IMHO. Even if the AC vendor does port to this platform, won't all the additional value be lost, as the standard code from the AC vendor is downloaded? Won't this stifle innovation by WTP vendors, rather than encourage it? Won't all the innovation have to come from AC vendors, only? Furthermore, this proposal does not provide any form of capital investment. Imagine a scenario where an AC vendor decides to get out of this business. The customers would have an AC with no way to get new WTP technologies supported (e.g., 802.11n). OK, so I assume we are not going to try to define a process where one can also do a brain transplant on the AC. So in this case, a customer merely needs to swap out their old ACs for ones from a new vendor? Oops! The overlap of supported WTPs between the two AC vendors may not cover all the WTPs in the legacy network. So to close I don't understand why the CAPWAP WG would be willing to accept a non-standard. Frankly, since AC vendors would have to create the WTP's images themselves, there is no reason why they cannot work with the WTP vendors directly to provide them with their own download mechanism. As I believe a few people stated already - this is the state we are in already. Pat R Calhoun CTO/Founder Airespace, Inc. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 11:33:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11661 for ; Fri, 11 Mar 2005 11:33:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0C4ED204C2; Fri, 11 Mar 2005 11:33:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E8C4E20483; Fri, 11 Mar 2005 11:33:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 344CD20483 for ; Fri, 11 Mar 2005 11:32:13 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by mail.frascone.com (Postfix) with ESMTP id D1B152041A for ; Fri, 11 Mar 2005 11:32:11 -0500 (EST) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2BGW9U28851 for ; Fri, 11 Mar 2005 18:32:09 +0200 (EET) X-Scanned: Fri, 11 Mar 2005 18:46:22 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j2BGkM3N009014 for ; Fri, 11 Mar 2005 18:46:22 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00LERyoF; Fri, 11 Mar 2005 18:46:21 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2BGVJU15645 for ; Fri, 11 Mar 2005 18:31:19 +0200 (EET) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 11 Mar 2005 10:31:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: Firmware download only protocol out of scope. Thread-Index: AcUmV7y1mBfg7INOTUqx9VVQ/xqcVg== From: To: X-OriginalArrivalTime: 11 Mar 2005 16:31:13.0428 (UTC) FILETIME=[BD902D40:01C52657] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Firmware download only protocol out of scope. Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 08:31:12 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I just wanted to clarify the chair's position. In my last email I = indicated that a firmware download only protocol does not meet the = charter objectives and thus is out of scope of the WG. =20 The only issue here is whether firmware download is a mandatory or = desirable requirement in the Objectives draft. =20 -Dorothy _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 11:34:11 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11751 for ; Fri, 11 Mar 2005 11:34:10 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 81CFE204B3; Fri, 11 Mar 2005 11:34:10 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 419BD204BF; Fri, 11 Mar 2005 11:34:06 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 927A3204C2 for ; Fri, 11 Mar 2005 11:33:23 -0500 (EST) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 22242204C7 for ; Fri, 11 Mar 2005 11:33:11 -0500 (EST) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j2BGMqvn000573 for ; Fri, 11 Mar 2005 11:22:53 -0500 (EST) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j2BGMhvn000267 for ; Fri, 11 Mar 2005 11:22:44 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: <5844A41F4E146044A2E8356C63285880080A9834@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUk9iMFoHGUzvlhQl2I19BqZ8pPlgBYD9uQ From: "Sadot, Emek (Emek)" To: "James Kempf" , "Dan Harkins" , "Michael Vakulenko" Cc: "Partha Narasimhan" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 11:32:00 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Jak, I do not argue the completion of the CAPWAP group upon satisfying the charter, the point I was trying to make relates to the fact that Partha's proposal may obsolete the need for re-chartering or make any enhancement to the protocol/arch moving forward. Regards, Emek -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 Sent: Wednesday, March 09, 2005 5:21 PM To: Sadot, Emek (Emek); Dan Harkins; Michael Vakulenko Cc: Partha Narasimhan; capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP=20 Whether or not we standardize a WTP control protocol or a code downloading protocol has nothing to do with whether CAPWAP is an ongoing process. When the CAPWAP charter is complete, the group can disband (this is what we did with SEND). Or not (other WGs like DNSEXT do this). It depends on what the WG members want to do and whether the IESG agrees. jak ----- Original Message ----- From: "Sadot, Emek (Emek)" To: "Dan Harkins" ; "Michael Vakulenko" Cc: "Partha Narasimhan" ; Sent: Wednesday, March 09, 2005 2:09 PM Subject: RE: [Capwap] A simpler approach to CAPWAP Partha's proposal introduces a great advantage related to future enhancement either within the 802.11 realm or associated to other technologies (e.g. 802.16). Bear in mind that defining a signaling protocol with particular embedded identifiers/object will required extensive extensions to maintain interoperability for any new feature/technology. Although I assume we cherish the CAPWAP group do we really want it to be an ongoing process? Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins Sent: Wednesday, March 09, 2005 2:12 PM To: Michael Vakulenko Cc: Partha Narasimhan; capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP On the contrary. If the CAPWAP protocol defines a full control plane and data frame encapsulation it will have to define standard APIs that need to be supported by all interoperable WTPs. If Partha's approach is taken then all that is defined is a discovery and download protocol. The WTC runs the downloaded image and that contains the (not-defined by CAPWAP) control and data frame protocols. No we're not talking about Java. The practicalities of achieving interoperability are solely on implementation of the discovery and download protocol. It is simple and therefore acheiving interoperability would not be hard. The practicalities of achieving stability and predictable performance are borne by the AC vendors who will guarantee that the image they provide to a WTP is stable and has predictable performance. Dan. On Wed, 09 Mar 2005 20:45:25 +0200 you wrote > Partha, > > I don't see how your suggestion makes things simpler. If CAPWAP would > follow your approach, this WG had to define standard APIs that needs > to be supported by all interoperable WTPs. These APIs will have to be > quite low-level and detailed to provide interface to 802.11 chipset, > Ethernet driver and operating system of the WTPs. > > Moreover, different WTP models may use different processor cores and > therefore firmware object code cannot be the same for all WTPs. (We > are not talking about Java here, are we?.. :-) ) > > The real complexity of what you have proposed is in fact higher than > traditional approach to protocol design, if you consider > practicalities of achieving interoperability, stability and > predictable performance for downloadable firmware. > > -- Michael V. > http://www.WaveCompass.com > > > At 06:58 PM 3/9/2005, Partha Narasimhan wrote: > > >The primary reason for the existence of the CAPWAP group is to solve > >an interoperability problem between ACs and WTPs from different > >vendors so that an end-user/customer has the choice of purchasing > >WTPs and ACs from different vendors. The existing marketplace is full > >of single-vendor solutions. To that extent, if an end-user is able to > >purchase a WTP from a vendor that is different than the vendor > >supplying the AC, but get them to interoperate with each other to > >create a functioning WLAN, then the end-user's objective is largely > >accomplished. > > > >Based on existing single-vendor WLAN solutions, it is obvious that > >the AC is where most of the control and management intelligence > >resides. It is not far from the truth to state the AC determines what > >functions are turned on at the WTPs and, hence, what features are > >available in the WLAN. Arguably, the interoperability problem can be > >restated as a customer's need to find WTPs that interoperate with > >his/her choice of AC. Or at a minimum, the WTPs need to follow and > >interoperate with the AC rather than the other way around. > > > >Interoperability can be achieved at multiple levels. In most of the > >current discussion on the CAPWAP mailing list, the primary assumption > >seems to be that interoperability requirement seems to be between the > >individual software that both the WTP and the AC ship with and/or > >boot up with. Once both the devices are up and running with their > >images, the WTPs discover one or more ACs and, assuming everything is > >set up right, one of the discovered ACs will configure and bring up > >the WTP as part of the customer's WLAN using a protocol that will be > >defined as part of the CAPWAP WG's work. > > > >Interoperability can also be achieved using a simpler mechanism where > >a WTP boots up, discovers one or more ACs to create an association > >with. As part of the discovery process, the WTP identifies itself > >(vendor ID, hardware version, software version, etc.). One of the > >discovered ACs can then instruct the WTP to download a firmware image > >that the WTP should boot itself with at the end of the download > >process. Upon booting itself with this downloaded image, the WTP runs > >a protocol, quite possibly proprietary to the AC vendor, contained in > >the downloaded image to create an association with an AC and get > >configured to be a member of the WLAN. An AC from one vendor might > >download an image to a WTP that is completely different than an AC > >from another vendor. This does solve the end-user's requirement of > >getting interoperability between WTPs and ACs from different vendors. > >The control protocol used to get the WTP to become a member of the > >WLAN controlled and managed by the AC is totally upto the AC vendor's > >choice. > > > >Essentially, the solution becomes a simple protocol for the WTP to > >discover one or more ACs, identify itself to the ACs, and download an > >image from the AC, if possible, that it will boot itself with - a > >secure download problem rather than a WLAN configuration problem from > >an interoperability perspective. This solves the CAPWAP problem of > >interoperability without requiring a full-fledged, new control > >protocol that all the WTP and AC vendors have to implement for > >interoperability. It is sufficient to implement the simpler secure > >download protocol to get to interoperability. This removes the > >necessity to negotiate capabilities (split MAC vs local MAC, one > >person's split may not suit another but we cannot have infinite > >permutations of a split, etc.) since the WTP assumes capabilities > >that are contained in the image that the AC vendor chooses to build > >for it. Another benefit of this approach is the extensibility of this > >simpler approach to future wireless technologies or extensions to > >existing technologies since these are folded into the downloaded > >image and hence are transparent to the secure download protocol itself. > > > >What are the issues with such a secure download protocol? This > >requires an AC to have a bootable image for every single WTP that the > >AC wants to interoperate with. Which could be a matter of > >differentiation for the AC vendors. If one vendor supports 2 models > >of WTPs, while another one decides to support 10, then the > >marketplace could choose if they like the feature set of the former > >enough that they dont mind the reduced set of interoperable WTPs or > >whether they like the greater interoperability of the latter AC. > >Secondly, we need a mechanism for the WTP and the AC, soon after the > >discovery process, to create a trust relationship between each other > >so that the WTP is sure it is not downloading code from a malicious > >entity masquerading as an AC and the AC is sure it is not supplying > >code to an entity masquerading as a WTP. > > > >The secure download approach shifts the burden of interoperability to > >the AC vendors and lowers the barrier for the WTP vendors that strive > >for interoperability. This shift is fine since the AC is the center > >of control and management for a WLAN and it is in the AC vendor's > >interests to get to wider interoperability, if they so chose to do. > >This is also aligned with the current market reality where the AC > >vendors' capabilities determine what features are available on the > >WLAN. The WTP vendors are required to implement a simpler protocol to > >get to interoperability with multiple AC vendors. The level of > >interoperability is always determined by individual choices by the > >vendors. For example, an AC that only supports split MAC may not > >interoperate with a WTP that only suppports the local MAC. Arguably, > >the interoperability achievable by the secure download approach is no > >worse than what is possible with a full-blown control protocol. Not > >to mention the simplicity of the protocol that the CAPWAP WG needs to > >work on. > > > >We intend to submit a proposal along these lines to the CAPWAP WG. It > >will involve a simple process as follows: > >- a WTP discovers one or more ACs, > >- the WTP identifies itself to the ACs that it discovered, > >- the WTP and one of the ACs create a mutual trust relationship, and > >- the WTP downloading an image from an AC. > >The details will be present in the draft that will follow soon. > > > >This approach is quite different from what has been discussed in the > >WG so far. It probably also has implications on the objectives draft. > >I would like to initiate some discussion on whether all the mandatory > >objectives as stated in the current objectives draft are still valid. > >I understand that the objectives were stated with a full-fledged, > >open and/or externally verifiable protocol in mind. If a certain set > >of objectives precludes such a simpler solution then we may need to > >re-visit and discuss that set of objectives. In other words, if a set > >of objectives as they currently stand are unnecessary for solving the > >problem that we started out to address, then we should discuss these > >now. > > > >Thanks > >partha > >_______________________________________________ > >Capwap mailing list > >Capwap@frascone.com > >http://mail.frascone.com/mailman/listinfo/capwap > > -- Michael Vakulenko > Phone: +972-54-776-2269 > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 13:17:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23240 for ; Fri, 11 Mar 2005 13:17:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CD212204F3; Fri, 11 Mar 2005 13:17:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58537204E7; Fri, 11 Mar 2005 13:17:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 224A9204E7 for ; Fri, 11 Mar 2005 13:16:30 -0500 (EST) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 6405220483 for ; Fri, 11 Mar 2005 13:16:27 -0500 (EST) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j2BIE8Mu012168; Fri, 11 Mar 2005 10:14:08 -0800 (PST) (envelope-from dharkins@trpz.com) Message-Id: <200503111814.j2BIE8Mu012168@homebrew.trpz.com> To: "Pat R. Calhoun" Cc: capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP In-Reply-To: Your message of "Fri, 11 Mar 2005 08:08:03 PST." <526F1C0D08561F4BB79022CB938A068B44FB74@AIREMAIL.airespace.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12166.1110564848.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 10:14:08 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Fri, 11 Mar 2005 08:08:03 PST you wrote > > Well, I must admit that I was a little surprised about a proposal to > create a non-standard. I agree with James and others that the CAPWAP WG > must really create a complete protocol, one that is well documented, and > is available for the network operators to use during the troubleshooting > process. There are complete and well-documented protocols that are available for network operators to use during troubleshooting that are simple. A non-standard? I know that isn't a serious comment since your next paragraph begins with "seriously". > Seriously, what exactly is being proposed here? We already have several > vendors with various protocols - the only difference is to allow a brain > transplant of WTPs. > > As an aside, I recollect ruling this out of the problem statement very > early on, so this whole discussion appears to be out of scope. That was before there was even a WG and the WG that came out after that "ruling" (makes it sound so official) was just supposed to come up with a taxonomy of architectures, nothing more. And your rulings carry no weight anyway. > As an AC vendor, the last thing that I really want to do is to have to > have a staff of people that have to understand the various WTP HW > architectures, not to mention the MACs which they all use, who spend > their time porting their code to different HW. Seriously, what's the > advantage to the AC vendor? It's a huge cost burden, and it really > doesn't solve the end problem. Sure, I can hear the "market advantage of > supporting more WTPs", but let's be fair here, we also have to provide a > solution that allows companies to be fiscally responsible. What's the benefit to the AC vendor? An operator can replace your switch with mine without having to chuck the couple hundred WTPs he purchased since my AC will happily give them all brain transplants. It's a compelling option to offer a customer and has obvious benefits to AC vendors. > You can imagine the scenario where a WTP vendor creates some significant > value, but is unable to get the most popular AC vendor to want to > support their platform - so this proposal actually stifles innovation, > IMHO. Even if the AC vendor does port to this platform, won't all the > additional value be lost, as the standard code from the AC vendor is > downloaded? Won't this stifle innovation by WTP vendors, rather than > encourage it? Won't all the innovation have to come from AC vendors, > only? Let's take your premise-- WTP vendor creates some significant value-- and see how it works with the all-encompassing control plane and data encaps idea. Since this new value was not part of the specification for the protocol it cannot be used. All he can do is send someone to the next IETF who will make a presentation to this WG, which will never die, that in the best case will take a year (that's assuming the other WTP vendors don't try to delay things in this highly-politicized IETF we have these days) before it appears as part of the standard. That is a serious disincentive to innovate. With the discovery and image download protocol innovation would not just come from AC vendors. The new value added by the WTP vendor would make his WTP more in demand and therefore AC vendors would be pressured to either support that WTP (in the event they don't already) or use the new feature just innovated (if they do). It has already been stated on this list that if the all-encompassing control plane plus data encapsulation route is taken that vendors can "differentiate themselves based on their network management system.... If the protocol is standardized, the vendors will find other areas to distinguish their products." By the way, that's "other areas" than the new value the WTP vendor came up with, to use your example. So we can differentiate ourselves on our network management system? Wow, that sounds really, really bad. It will constrain technological innovation but we can all become java programmers to make our GUI more pretty! Thanks but no thanks. > Furthermore, this proposal does not provide any form of capital > investment. Protocols do not provide capital investments. So proposals for protocols will necessarily not provide them either. > Imagine a scenario where an AC vendor decides to get out of > this business. The customers would have an AC with no way to get new WTP > technologies supported (e.g., 802.11n). OK, so I assume we are not going > to try to define a process where one can also do a brain transplant on > the AC. So in this case, a customer merely needs to swap out their old > ACs for ones from a new vendor? Oops! The overlap of supported WTPs > between the two AC vendors may not cover all the WTPs in the legacy > network. In the scenario you describe the customer would purchase an AC from a vendor that provided a greater "overlap", ideally one that supported all the legacy network. Also your mention of 11n is a non-sequitur. > So to close I don't understand why the CAPWAP WG would be willing to > accept a non-standard. Frankly, since AC vendors would have to create > the WTP's images themselves, there is no reason why they cannot work > with the WTP vendors directly to provide them with their own download > mechanism. As I believe a few people stated already - this is the state > we are in already. Yes, that is what we have today. And a plethora of "download mechanisms" is a pain. It is a problem today that needs a standard from the IETF to solve. Having a single standard (real standard, not "non-standard" by the way) method of discovery and image download will make it much easier to support the scenario that prompted the formation of this WG. The all-encompassing control plane plus data encapsulation protocol idea will necessarily constrain development and stifle technological innovation (you can only configure what the protocol knows about, you can only gather statistics on things the protocol knows about, you can only monitor what the protocol knows about, etc). Either that or it will be a hideously complex and unimplementable nightmare. Dan. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 13:24:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23753 for ; Fri, 11 Mar 2005 13:24:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7DCE4204F3; Fri, 11 Mar 2005 13:24:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 05251204E7; Fri, 11 Mar 2005 13:24:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9C3D1204E7 for ; Fri, 11 Mar 2005 13:23:48 -0500 (EST) Received: from WNIMAIL.WoodsideNet.Com (wnifwl.woodsidenet.com [65.192.186.2]) by mail.frascone.com (Postfix) with ESMTP id A6051204DF for ; Fri, 11 Mar 2005 13:23:46 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: <3FFBC907DD03A34CA4410C5C745DEB1205C4E13B@wnimail.WoodsideNet.Com> Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUmZovH8UhikeWxRfmAhZX/w6vv3QAAC/8A From: "Paul Lambert" To: "Dan Harkins" , "Pat R. Calhoun" Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 10:23:39 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > What's the benefit to the AC vendor? An operator can replace=20 > your switch with mine without having to chuck the couple=20 > hundred WTPs he purchased since my AC will happily give them=20 > all brain transplants. It's a compelling option to offer a=20 > customer and has obvious benefits to AC vendors. Huh??? Since when is it possible to easily write firmware for a competitors product? Please provide me with the coordinates of your new Universe. There are some major differences between our phyical realities. =20 Paul _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 13:32:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24291 for ; Fri, 11 Mar 2005 13:32:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 20748204FE; Fri, 11 Mar 2005 13:32:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58826204EC; Fri, 11 Mar 2005 13:32:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7877C204EC for ; Fri, 11 Mar 2005 13:31:09 -0500 (EST) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id 22FF6204E7 for ; Fri, 11 Mar 2005 13:31:07 -0500 (EST) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j2BISr4X017600 for ; Fri, 11 Mar 2005 13:28:53 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j2BISe4X017316 for ; Fri, 11 Mar 2005 13:28:43 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUkyTkZeOJkvi+lQLCb7JYxtzARZAARVAOg From: "Mani, Mahalingam (Mahalingam)" To: "Partha Narasimhan" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 11:31:01 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Secure firmware download is a worthy objective (which is already in). But it is only one of the objectives. As a protocol The taxonomy study has not indicated an architectural trend towards what is being proposed. That exercise was undertaken to normalize architectural variants. It had proved to be a challenge and was well handled. That does not mean the challenge has passed. That is why we wish to nail it down in the Objectives - without discouraging non-normative implementations. CAPWAP WG is not here to dictate a new architectural mandate - or make presumptions on how WTPs and ACs should shape up in hardware and firmware to work with each other.=20 Our goal in IETF is to define an interoperable protocol interface for such already identified class of architectures that works. That was the architecture taxonomy exercise (and the ongoing liaison with IEEE 802.11 to further clarify & validate as much as it can and as needed). Its goal is to design a protocol to address the normalized architectural framework and address the problems explicitly described in RFC3990 (and more). Here is what CAPWAP WG work was founded on: To address the problem of managing a large number of (wireless) devices of a class (WLAN APs) whose primary functions are to (a) discover (and associate with) (b) configure (as often)/provision (one-time) (c) monitor (unsolicited or solicited) (d) control (e) secure 1. the mgmt. communication to it 2. the network (from possible rogue instances among other things) by authent., admission, authorization 3. the client (from possible rogue controllers) And to be able to do so in specific determinate ways verifiable for interoperability. If we left the above communications to the machinations of the individual implementations - that does not meet our objectives. Nor is there much of a need for IETF - for CAPWAP or many other protocols. So, setting aside the implied architectural mandate of the proposal below; We welcome proposals addressing the RFC3990 stated-problems and Objectives. Regards, -mani =3D=3D=3D=3D=3D=3D -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Partha Narasimhan Sent: Wednesday, March 09, 2005 8:59 AM To: capwap@frascone.com Subject: [Capwap] A simpler approach to CAPWAP The primary reason for the existence of the CAPWAP group is to solve an interoperability problem between ACs and WTPs from different vendors so that an end-user/customer has the choice of purchasing WTPs and ACs from different vendors. The existing marketplace is full of single-vendor solutions. To that extent, if an end-user is able to purchase a WTP from a vendor that is different than the vendor supplying the AC, but get them to interoperate with each other to create a functioning WLAN, then the end-user's objective is largely accomplished. Based on existing single-vendor WLAN solutions, it is obvious that the AC is where most of the control and management intelligence resides. It is not far from the truth to state the AC determines what functions are turned on at the WTPs and, hence, what features are available in the WLAN. Arguably, the interoperability problem can be restated as a customer's need to find WTPs that interoperate with his/her choice of AC. Or at a minimum, the WTPs need to follow and interoperate with the AC rather than the other way around.=20 Interoperability can be achieved at multiple levels. In most of the current discussion on the CAPWAP mailing list, the primary assumption seems to be that interoperability requirement seems to be between the individual software that both the WTP and the AC ship with and/or boot up with. Once both the devices are up and running with their images, the WTPs discover one or more ACs and, assuming everything is set up right, one of the discovered ACs will configure and bring up the WTP as part of the customer's WLAN using a protocol that will be defined as part of the CAPWAP WG's work. Interoperability can also be achieved using a simpler mechanism where a WTP boots up, discovers one or more ACs to create an association with. As part of the discovery process, the WTP identifies itself (vendor ID, hardware version, software version, etc.). One of the discovered ACs can then instruct the WTP to download a firmware image that the WTP should boot itself with at the end of the download process. Upon booting itself with this downloaded image, the WTP runs a protocol, quite possibly proprietary to the AC vendor, contained in the downloaded image to create an association with an AC and get configured to be a member of the WLAN. An AC from one vendor might download an image to a WTP that is completely different than an AC from another vendor. This does solve the end-user's requirement of getting interoperability between WTPs and ACs from different vendors. The control protocol used to get the WTP to become a member of the WLAN controlled and managed by the AC is totally upto the AC vendor's choice. Essentially, the solution becomes a simple protocol for the WTP to discover one or more ACs, identify itself to the ACs, and download an image from the AC, if possible, that it will boot itself with - a secure download problem rather than a WLAN configuration problem from an interoperability perspective. This solves the CAPWAP problem of interoperability without requiring a full-fledged, new control protocol that all the WTP and AC vendors have to implement for interoperability. It is sufficient to implement the simpler secure download protocol to get to interoperability. This removes the necessity to negotiate capabilities (split MAC vs local MAC, one person's split may not suit another but we cannot have infinite permutations of a split, etc.) since the WTP assumes capabilities that are contained in the image that the AC vendor chooses to build for it. Another benefit of this approach is the extensibility of this simpler approach to future wireless technologies or extensions to existing technologies since these are folded into the downloaded image and hence are transparent to the secure download protocol itself. What are the issues with such a secure download protocol? This requires an AC to have a bootable image for every single WTP that the AC wants to interoperate with. Which could be a matter of differentiation for the AC vendors. If one vendor supports 2 models of WTPs, while another one decides to support 10, then the marketplace could choose if they like the feature set of the former enough that they dont mind the reduced set of interoperable WTPs or whether they like the greater interoperability of the latter AC. Secondly, we need a mechanism for the WTP and the AC, soon after the discovery process, to create a trust relationship between each other so that the WTP is sure it is not downloading code from a malicious entity masquerading as an AC and the AC is sure it is not supplying code to an entity masquerading as a WTP.=20 The secure download approach shifts the burden of interoperability to the AC vendors and lowers the barrier for the WTP vendors that strive for interoperability. This shift is fine since the AC is the center of control and management for a WLAN and it is in the AC vendor's interests to get to wider interoperability, if they so chose to do. This is also aligned with the current market reality where the AC vendors' capabilities determine what features are available on the WLAN. The WTP vendors are required to implement a simpler protocol to get to interoperability with multiple AC vendors. The level of interoperability is always determined by individual choices by the vendors. For example, an AC that only supports split MAC may not interoperate with a WTP that only suppports the local MAC. Arguably, the interoperability achievable by the secure download approach is no worse than what is possible with a full-blown control protocol. Not to mention the simplicity of the protocol that the CAPWAP WG needs to work on. We intend to submit a proposal along these lines to the CAPWAP WG. It will involve a simple process as follows: - a WTP discovers one or more ACs, - the WTP identifies itself to the ACs that it discovered, - the WTP and one of the ACs create a mutual trust relationship, and - the WTP downloading an image from an AC. The details will be present in the draft that will follow soon. This approach is quite different from what has been discussed in the WG so far. It probably also has implications on the objectives draft. I would like to initiate some discussion on whether all the mandatory objectives as stated in the current objectives draft are still valid. I understand that the objectives were stated with a full-fledged, open and/or externally verifiable protocol in mind. If a certain set of objectives precludes such a simpler solution then we may need to re-visit and discuss that set of objectives. In other words, if a set of objectives as they currently stand are unnecessary for solving the problem that we started out to address, then we should discuss these now. Thanks partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 13:49:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25344 for ; Fri, 11 Mar 2005 13:49:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F2F2620506; Fri, 11 Mar 2005 13:49:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 08EA1204FE; Fri, 11 Mar 2005 13:49:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 11B4D204FE for ; Fri, 11 Mar 2005 13:48:30 -0500 (EST) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 47029204F3 for ; Fri, 11 Mar 2005 13:48:28 -0500 (EST) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j2BIkDvV012301; Fri, 11 Mar 2005 10:46:13 -0800 (PST) (envelope-from dharkins@trpz.com) Message-Id: <200503111846.j2BIkDvV012301@homebrew.trpz.com> To: "Paul Lambert" Cc: "Pat R. Calhoun" , capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP In-Reply-To: Your message of "Fri, 11 Mar 2005 10:23:39 PST." <3FFBC907DD03A34CA4410C5C745DEB1205C4E13B@wnimail.WoodsideNet.Com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12299.1110566773.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 10:46:13 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Fri, 11 Mar 2005 10:23:39 PST you wrote > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > > > What's the benefit to the AC vendor? An operator can replace > > your switch with mine without having to chuck the couple > > hundred WTPs he purchased since my AC will happily give them > > all brain transplants. It's a compelling option to offer a > > customer and has obvious benefits to AC vendors. > > Huh??? Since when is it possible to easily write firmware for a > competitors product? Notice how I didn't say "easy"? And it requires the specs from the competitor's products or the willful cooperation of the competitor. Notice how I didn't say "competitor" either. I was talking about a situation where WTPs speak a standard discovery and image download protocol and swapping out ACs and leaving WTPs is possible. Saying "replace my switch with your's" or "replace switch Foo with switch Bar" would not alter the meaning of my statement. Please substitute either of those suggestions if "replace your switch with mine" is causing you conniptions. > Please provide me with the coordinates of your new Universe. There are > some major differences between our phyical realities. It's all relative Paul. From your perspective those differences seem to put me in a different universe. Perhaps it is you, though. (Cue soundtrack to "The Outer Limits"). Dan. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 14:35:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00668 for ; Fri, 11 Mar 2005 14:35:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 167542050F; Fri, 11 Mar 2005 14:35:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 588CD20509; Fri, 11 Mar 2005 14:35:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 99C2B204FE for ; Fri, 11 Mar 2005 14:34:28 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mail.frascone.com (Postfix) with ESMTP id B8793204F3 for ; Fri, 11 Mar 2005 14:34:26 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 67so1554560wri for ; Fri, 11 Mar 2005 11:34:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=nVw4E5T1HCnklu/+/AK+Awd9m0N2Fp8nyCUsM8nqPybN0zrRW4KoxEFlFL7CFh2YG0zIMwHPLS7lqHGiG6TG0eI8KMaZFnkJQoGWgWy29u2kK6SdTl8zX0VT+d2b2R8Nl6Tck5d8CU9IltYcVhPIQ6FVttptubNE+NrKU1DMUjo= Received: by 10.54.62.20 with SMTP id k20mr1072867wra; Fri, 11 Mar 2005 11:34:25 -0800 (PST) Received: by 10.54.45.70 with HTTP; Fri, 11 Mar 2005 11:34:25 -0800 (PST) Message-ID: From: Keerti Melkote Reply-To: Keerti Melkote To: "Pat R. Calhoun" Subject: Re: [Capwap] A simpler approach to CAPWAP Cc: capwap@frascone.com In-Reply-To: <526F1C0D08561F4BB79022CB938A068B44FB74@AIREMAIL.airespace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <526F1C0D08561F4BB79022CB938A068B44FB74@AIREMAIL.airespace.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 11:34:25 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable On Fri, 11 Mar 2005 08:08:03 -0800, Pat R. Calhoun wrote: >=20 > Well, I must admit that I was a little surprised about a proposal to > create a non-standard. I agree with James and others that the CAPWAP WG > must really create a complete protocol, one that is well documented, and > is available for the network operators to use during the troubleshooting > process. >=20 Can you tell me how the CAPWAP group is going to address the multi-BSSID issue that was raised by Partha or for that matter other new capabilities that will inevitably emerge? We perform packet captures on our APs, will there be another information element that takes care of that too. Lets not obfuscate the real issue here. A standard for the sake of a standard is not necessarily a good thing. Especially one that is designed to curb innovation in the name of interoperability. > Seriously, what exactly is being proposed here? We already have several > vendors with various protocols - the only difference is to allow a brain > transplant of WTPs. >=20 What is being proposed is a very simple way to achieve interoperability between WTPs and ACs without requiring a heavy-duty protocol that attempts to accommodate every innovation that might occur and create a bloated proposal that does not achieve the desired end goal of interoperability. Do I need to remind folks of the ATM Forum? > As an aside, I recollect ruling this out of the problem statement very > early on, so this whole discussion appears to be out of scope. >=20 You ruling something out, means nothing to me. I am disappointed that the chairs fail to recognize the real issues and continue to pursue academic objectives without regard to market realities. > As an AC vendor, the last thing that I really want to do is to have to > have a staff of people that have to understand the various WTP HW > architectures, not to mention the MACs which they all use, who spend > their time porting their code to different HW. Seriously, what's the > advantage to the AC vendor? It's a huge cost burden, and it really > doesn't solve the end problem. Sure, I can hear the "market advantage of > supporting more WTPs", but let's be fair here, we also have to provide a > solution that allows companies to be fiscally responsible. >=20 Pat =E2=80=93 you and I both know that a protocol does not solve your busin= ess issue. A vendor is either committed to interoperability or not. And it takes money to achieve this. I can't comment on the particulars of your business issues. We are committed to interoperability and it does mean having a staff that works on achieving interoperability. The advantage is to the customer. They get to mix and match ACs and WTPs. > You can imagine the scenario where a WTP vendor creates some significant > value, but is unable to get the most popular AC vendor to want to > support their platform - so this proposal actually stifles innovation, > IMHO. Even if the AC vendor does port to this platform, won't all the > additional value be lost, as the standard code from the AC vendor is > downloaded? Won't this stifle innovation by WTP vendors, rather than > encourage it? Won't all the innovation have to come from AC vendors, > only? >=20 Interesting point of view. Lets say a WTP vendor comes up with some unique value added feature set. The AC vendors do not support it. How does your proposal help the WTP vendor exactly? The solution is the same regardless of whether you have a control protocol or a download protocol. The WTP vendor comes up with their extensions and has a business discussion with AC vendors to support their value add. I think both proposals solve this business problem. The download protocol does this more expeditiously for the WTP vendor, the AC vendor and the customer. > Furthermore, this proposal does not provide any form of capital > investment. Imagine a scenario where an AC vendor decides to get out of > this business. The customers would have an AC with no way to get new WTP > technologies supported (e.g., 802.11n). OK, so I assume we are not going > to try to define a process where one can also do a brain transplant on > the AC. So in this case, a customer merely needs to swap out their old > ACs for ones from a new vendor? Oops! The overlap of supported WTPs > between the two AC vendors may not cover all the WTPs in the legacy > network. >=20 Interesting theory. In capitalism, where there is opportunity, usually there is someone to take it. Lets take your example and say a vendor decides to get out of this business (many enterprise customers are in this state now as we speak). The customer is now stuck with an expensive deployment of WTPs and ACs that are now obsolete. All the customer has to do is simply swap out the obsolete ACs with one that supports the deployed WTPs and the WLAN is back in action. The brain transplant provides investment protection to the customer assuming an enterprising AC vendor decides to take the burden of getting the installed WTPs to work with their ACs. > So to close I don't understand why the CAPWAP WG would be willing to > accept a non-standard. Frankly, since AC vendors would have to create > the WTP's images themselves, there is no reason why they cannot work > with the WTP vendors directly to provide them with their own download > mechanism. As I believe a few people stated already - this is the state > we are in already. >=20 The goal is not a non-standard. It is a simpler standard that delivers the key objective of interoperability without locking down innovation. Keerti Melkote Founder Aruba Networks > Pat R Calhoun > CTO/Founder > Airespace, Inc. >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 15:00:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02262 for ; Fri, 11 Mar 2005 15:00:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2511F20515; Fri, 11 Mar 2005 15:00:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A08952050F; Fri, 11 Mar 2005 15:00:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B59A1204F8 for ; Fri, 11 Mar 2005 14:59:59 -0500 (EST) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id BFAA42035E for ; Fri, 11 Mar 2005 14:59:57 -0500 (EST) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j2BJvh4X000009 for ; Fri, 11 Mar 2005 14:57:44 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j2BJvf4X029949 for ; Fri, 11 Mar 2005 14:57:41 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUmcX0UCaJ/9357S6SPPDhJw71nHwAAGa7A From: "Mani, Mahalingam (Mahalingam)" To: "Keerti Melkote" , "Pat R. Calhoun" Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 13:00:02 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Keerti, See inline. -mani =3D=3D=3D=3D=3D=3D [...] >=20 You ruling something out, means nothing to me. I am disappointed that the chairs fail to recognize the real issues and continue to pursue academic objectives without regard to market realities. [Mani, Mahalingam (Mahalingam)] this is not an academic objective. If it turns out to achieve something in the academic realm as well - I am sure the erudite ones in the WG will be glad to have contributed. The chairs have no intentions to tolerate proposals that make a mockery of IETF or CAPWAP objectives and charter. Nor proposals for the sake of one. Nor to detract from charter goals the WG has shown consensus (including the current proponent-s) on; while still being open to arguments on serious validation issues, if any, including the charter; this will require more than mere assertions. I would urge, finally, to keep the debate, discussions and objective statements focusing on problems and/or issues at hand and not mix unjustifiable rhetoric. > As an AC vendor, the last thing that I really want to do is to have to [Mani, Mahalingam (Mahalingam)] [...] Keerti Melkote Founder Aruba Networks > Pat R Calhoun > CTO/Founder > Airespace, Inc. >=20 > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > [Mani, Mahalingam (Mahalingam)] -mani _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 15:07:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03144 for ; Fri, 11 Mar 2005 15:07:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E27322051C; Fri, 11 Mar 2005 15:07:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DAEF0204F8; Fri, 11 Mar 2005 15:07:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B6096204F8 for ; Fri, 11 Mar 2005 15:06:34 -0500 (EST) Received: from WNIMAIL.WoodsideNet.Com (wnifwl.woodsidenet.com [65.192.186.2]) by mail.frascone.com (Postfix) with ESMTP id E4C952035E for ; Fri, 11 Mar 2005 15:06:32 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: <3FFBC907DD03A34CA4410C5C745DEB1205C4E15E@wnimail.WoodsideNet.Com> Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUmcXLAepADXAglQo+l9AN4efgDCAAAnoxQ From: "Paul Lambert" To: "Keerti Melkote" , "Pat R. Calhoun" Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 12:06:30 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable >> From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Keerti Melkote >Interesting theory. In capitalism, where there is opportunity, usually there is someone to take it. >Lets take your example and say a vendor decides to get out of=20 >this business (many enterprise customers are in this state now=20 >as we speak). The customer is now stuck with an expensive=20 >deployment of WTPs and ACs that are now obsolete. All the=20 >customer has to do is simply swap out the obsolete ACs with=20 >one that supports the deployed WTPs and the WLAN is back in=20 >action. The brain transplant provides investment protection=20 >to the customer assuming an enterprising AC vendor decides=20 >to take the burden of getting the installed WTPs to work with=20 >their ACs.=20 What if I'm an AP/WTP vendor. Without very close cooporation with the AC vendor, it would be impossible to create a compatible AP/WTP. This meets my definition of a 'closed' and proprietary system. If I'm an AC vendor, I can only field a 'brain transplant' if I have a very close relationship with the WTP vendor. The relationship must either include full documentation of the WTP hardware interfaces, OS and board level information for the AC vendor to write code, or a full set of protocol signaling that includes the data encapsulation techniques and control signaling. This required level of coorporation also meets my definition of a 'closed' and proprietary system. Note that open publishing of the data encapsulation and control signaling suddenly opens the system to anyone and creates a true interoperable marketplace.=20 Brain transplants may have some interesting capabilites, but the brain still needs to speak a known and common language to be useful. If the WTP-to-AC signaling is proprietary, the system is proprietary. =20 Paul _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 15:15:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04126 for ; Fri, 11 Mar 2005 15:15:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 306E120520; Fri, 11 Mar 2005 15:15:09 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 150D020512; Fri, 11 Mar 2005 15:15:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BDEAF204F8 for ; Fri, 11 Mar 2005 15:14:11 -0500 (EST) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id E303E2035E for ; Fri, 11 Mar 2005 15:14:09 -0500 (EST) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j2BKBu4X019016 for ; Fri, 11 Mar 2005 15:11:56 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j2BKBt4X018985 for ; Fri, 11 Mar 2005 15:11:55 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52676.E65B23FA" Message-ID: Thread-Topic: Minutes of IETF62 CAPWAP sessions. Thread-Index: AcUmdsJAfprkzmZEQlOKO9K6f0jRig== From: "Mani, Mahalingam (Mahalingam)" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Minutes of IETF62 CAPWAP sessions. Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 13:14:16 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C52676.E65B23FA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The minutes of the meeting are available at http://www.capwap.org/ietf62 as well as http://ietf.webdav.org/capwap/ietf62/ along with the presentations. =20 Thanks to Partha Narasimhan for taking the minutes. =20 Regards, -Mani, DorothyG =3D=3D=3D=3D=3D=3D =20 ------_=_NextPart_001_01C52676.E65B23FA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The minutes of the meeting are available at http://www.capwap.org/ietf62 = as well as http://ietf.webdav.org/cap= wap/ietf62/ along with the presentations.

 

Thanks to Partha Narasimhan for taking the = minutes.

 

Regards,

-Mani, DorothyG

=3D=3D=3D=3D=3D=3D

 

------_=_NextPart_001_01C52676.E65B23FA-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 15:24:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04797 for ; Fri, 11 Mar 2005 15:24:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 04F9F20523; Fri, 11 Mar 2005 15:24:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 435BB204F3; Fri, 11 Mar 2005 15:24:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 32F5A204F3 for ; Fri, 11 Mar 2005 15:23:01 -0500 (EST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mail.frascone.com (Postfix) with ESMTP id C52A82035E for ; Fri, 11 Mar 2005 15:22:59 -0500 (EST) Received: by wproxy.gmail.com with SMTP id 67so1577917wri for ; Fri, 11 Mar 2005 12:22:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ZUIOgGA8SDC0PPMP1lBk3DqAXaPHKM0M2D6eW8j9RK6c2tI+juqrINYdvs/EkI6g9mOXRTIb9axwI1HEeDSPJiSteqE7KItj7+58UxQBsoFC3Kyq3l/ItUFBN8TtnVxOolb9qfwgy6ukHwMG1ZEdvxvai+TyLHgF66VNvb5ICyA= Received: by 10.54.25.18 with SMTP id 18mr132103wry; Fri, 11 Mar 2005 12:22:51 -0800 (PST) Received: by 10.54.45.70 with HTTP; Fri, 11 Mar 2005 12:22:49 -0800 (PST) Message-ID: From: Keerti Melkote Reply-To: Keerti Melkote To: "Mani, Mahalingam (Mahalingam)" Subject: Re: [Capwap] A simpler approach to CAPWAP Cc: "Pat R. Calhoun" , capwap@frascone.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 12:22:49 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Mani, See inline. -Keerti On Fri, 11 Mar 2005 13:00:02 -0700, Mani, Mahalingam (Mahalingam) wrote: > Keerti, > > See inline. > > -mani > ====== > > [...] > > > > You ruling something out, means nothing to me. I am disappointed that > the chairs fail to recognize the real issues and continue to pursue > academic objectives without regard to market realities. > > [Mani, Mahalingam (Mahalingam)] this is not an academic objective. If it > turns out to achieve something in the academic realm as well - I am sure > the erudite ones in the WG will be glad to have contributed. > > The chairs have no intentions to tolerate proposals that make a mockery > of IETF or CAPWAP objectives and charter. > If questioning objectives is a mockery of the IETF or CAPWAP, then I fail to see how this is in the spirit of open debate which the IETF has always stood for. The fact remains that there is not a single substantive argument which says a download protocol does not meet the market objective of interoperability between ACs and WTPs. The arguments seem to center around the fact that the method of communication seem proprietary but never the fact that an AC and a WTP from different vendors can be made interoperable. However, we continue to proceed without accepting this as an alternative to the heavy duty protocols that have been submitted today. I agree that it does not deliver interoperability of the kind this group seems to prefer. But customers are NOT asking for this. They are asking for interoperability. Full Stop. Not of a specific kind. > Nor proposals for the sake of one. > > Nor to detract from charter goals the WG has shown consensus (including > the current proponent-s) on; while still being open to arguments on > serious validation issues, if any, including the charter; this will > require more than mere assertions. > > I would urge, finally, to keep the debate, discussions and objective > statements focusing on problems and/or issues at hand and not mix > unjustifiable rhetoric. > > > As an AC vendor, the last thing that I really want to do is to have to > [Mani, Mahalingam (Mahalingam)] [...] > > Keerti Melkote > Founder > Aruba Networks > > > Pat R Calhoun > > CTO/Founder > > Airespace, Inc. > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > [Mani, Mahalingam (Mahalingam)] -mani > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 15:53:12 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06625 for ; Fri, 11 Mar 2005 15:53:11 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 145EC2050E; Fri, 11 Mar 2005 15:53:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9711B20514; Fri, 11 Mar 2005 15:53:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7879720514 for ; Fri, 11 Mar 2005 15:52:26 -0500 (EST) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 6C2532050E for ; Fri, 11 Mar 2005 15:52:20 -0500 (EST) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j2BKo4MY012763; Fri, 11 Mar 2005 12:50:04 -0800 (PST) (envelope-from dharkins@trpz.com) Message-Id: <200503112050.j2BKo4MY012763@homebrew.trpz.com> To: "Paul Lambert" Cc: "Keerti Melkote" , "Pat R. Calhoun" , capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP In-Reply-To: Your message of "Fri, 11 Mar 2005 12:06:30 PST." <3FFBC907DD03A34CA4410C5C745DEB1205C4E15E@wnimail.WoodsideNet.Com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12761.1110574204.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 12:50:04 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Paul, I don't want to get into a symantic game about whose private definition of the word "proprietary" is more correct but something here deserves a comment. On Fri, 11 Mar 2005 12:06:30 PST you wrote > > If I'm an AC vendor, I can only field a 'brain transplant' if I have a > very close relationship with the WTP vendor. The relationship must > either include full documentation of the WTP hardware interfaces, OS and > board level information for the AC vendor to write code, or a full set > of protocol signaling that includes the data encapsulation techniques > and control signaling. You're right. The relationship would probably include all the information necessary for an AC vendor to port his code to a WTP vendor's platform. Contrary examples exist (netbsd runs on a playstation2) but that is, as you have pointed out, not "easy". Or, you say, "a full set of protocol signaling that includes the data encapsulation techniques and control signalling." That's exactly why the all-encompasing control plane and data encapsulation option is so unappealing. Either your set is the same as everyone else's set (in which case it wouldn't appear in your argument so let's just dismiss that fiction immediately) or something in someone's set of control signaling-- perhaps your's!-- is going to be left out of the "standard". Put yourself in that place. Your chipset has some whippy-dippy feature that no one else's has but the "standard" doesn't allow for control or management of it. Whaddya do? Dan. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 16:02:15 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07219 for ; Fri, 11 Mar 2005 16:02:12 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7025020532; Fri, 11 Mar 2005 16:02:10 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2B95B20523; Fri, 11 Mar 2005 16:02:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C6C0220523 for ; Fri, 11 Mar 2005 16:01:26 -0500 (EST) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 002F720520 for ; Fri, 11 Mar 2005 16:01:18 -0500 (EST) Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j2BKoxvn009819 for ; Fri, 11 Mar 2005 15:50:59 -0500 (EST) Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j2BKogvn009398 for ; Fri, 11 Mar 2005 15:50:46 -0500 (EST) x-mimeole: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUmeCal7MgqoS3JTSKKTSP0PlyEmAAAMedA From: "Mani, Mahalingam (Mahalingam)" To: "Keerti Melkote" Cc: "Pat R. Calhoun" , X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 14:01:07 -0700 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Further on this...inline. -mani =3D=3D=3D=3D=3D=3D -----Original Message----- [...] >=20 > You ruling something out, means nothing to me. I am disappointed that > the chairs fail to recognize the real issues and continue to pursue > academic objectives without regard to market realities. >=20 > [Mani, Mahalingam (Mahalingam)] this is not an academic objective. If it > turns out to achieve something in the academic realm as well - I am sure > the erudite ones in the WG will be glad to have contributed. >=20 > The chairs have no intentions to tolerate proposals that make a mockery > of IETF or CAPWAP objectives and charter. >=20 If questioning objectives is a mockery of the IETF or CAPWAP, then I fail to see how this is in the spirit of open debate which the IETF has always stood for. [Mani, Mahalingam (Mahalingam)] to clarify - we are not assuming mockery yet. We are just forewarning that it does not become one. On Openness: it still does. That's why we are still debating in this list. It perhaps also shows openness to discussing the protocol in anticipation of further details and clarification without presupposing that it only means what it says now. The fact remains that there is not a single substantive argument which says a download protocol does not meet the market objective of interoperability between ACs and WTPs. The arguments seem to center [Mani, Mahalingam (Mahalingam)]=20 [Mani, Mahalingam (Mahalingam)] that is the non-mockery component. around the fact that the method of communication seem proprietary but never the fact that an AC and a WTP from different vendors can be made interoperable. However, we continue to proceed without accepting this as an alternative to the heavy duty protocols that have been submitted today. I agree that it does not deliver interoperability of the kind this group seems to prefer. But customers are NOT asking for this. They are asking for interoperability. Full Stop. Not of a specific kind. [Mani, Mahalingam (Mahalingam)] if customers are NOT asking for this - having contributed to this group this Partha's current inputs (along with earlier ones) as well as other constituents' - which includes customers - (and we are consciously making an attempt to explicitly poll many - as those who have followed the WG activities have been notified in earlier sessions) - including yours in proxy of customers. As chairs We will continue to always listen. [We also are responsible to filter spurious ones]. [If there's WG consensus they *are asking for this* as has been the vector indication so far - the WG will continue on identifying protocol solution based on the charter.] -mani > Nor proposals for the sake of one. >=20 > Nor to detract from charter goals the WG has shown consensus (including > the current proponent-s) on; while still being open to arguments on > serious validation issues, if any, including the charter; this will > require more than mere assertions. >=20 > I would urge, finally, to keep the debate, discussions and objective > statements focusing on problems and/or issues at hand and not mix > unjustifiable rhetoric. >=20 > > As an AC vendor, the last thing that I really want to do is to have to > [Mani, Mahalingam (Mahalingam)] [...] >=20 > Keerti Melkote > Founder > Aruba Networks >=20 > > Pat R Calhoun > > CTO/Founder > > Airespace, Inc. > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap > > > [Mani, Mahalingam (Mahalingam)] -mani > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap >=20 > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Mar 11 16:36:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09738 for ; Fri, 11 Mar 2005 16:36:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 636AD20538; Fri, 11 Mar 2005 16:36:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B79AF2052E; Fri, 11 Mar 2005 16:36:04 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3115A2052E for ; Fri, 11 Mar 2005 16:35:24 -0500 (EST) Received: from AIREMAIL.airespace.com (mail.airespace.com [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id 2148A20528 for ; Fri, 11 Mar 2005 16:35:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Capwap] A simpler approach to CAPWAP Message-ID: <526F1C0D08561F4BB79022CB938A068B44FB83@AIREMAIL.airespace.com> Thread-Topic: [Capwap] A simpler approach to CAPWAP Thread-Index: AcUmcVYq51JqLXg+SCerBnkTrYEoVQAD1IAg From: "Pat R. Calhoun" To: "Keerti Melkote" Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Fri, 11 Mar 2005 13:32:22 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Can you tell me how the CAPWAP group is going to address the multi-BSSID issue that was raised by Partha or for that matter other new capabilities that will inevitably emerge? We perform packet captures on our APs, will there be another information element that takes care of that too. Lets not obfuscate the real issue here. A standard for the sake of a standard is not necessarily a good thing. Especially one that is designed to curb innovation in the name of interoperability. A WTP can specify how many BSSIDs it can handle, and the AC acts accordingly. This is nothing that even your proposal can really do anything about. If a vendor comes to you with a WTP whose MAC can only handle a single MAC address, then you have that restriction as wel. What is being proposed is a very simple way to achieve interoperability between WTPs and ACs without requiring a heavy-duty protocol that attempts to accommodate every innovation that might occur and create a bloated proposal that does not achieve the desired end goal of interoperability. At a huge cost. This is not interoperability. This is restricting which vendors in the market will be able to be successful, based solely on their relationship with the AC vendors. You ruling something out, means nothing to me. I am disappointed that the chairs fail to recognize the real issues and continue to pursue academic objectives without regard to market realities. I would argue that your approach harms the market even more. Pat - you and I both know that a protocol does not solve your business issue. A vendor is either committed to interoperability or not. And it takes money to achieve this. I can't comment on the particulars of your business issues. We are committed to interoperability and it does mean having a staff that works on achieving interoperability. The advantage is to the customer. They get to mix and match ACs and WTPs. ok, so let me ask the question a different way. Say a new start-up comes up with the latest and greatest MAC that solves world hunger. They recognize that CAPWAP is required, so they start to partner up. Now in order for this vendor to be able to play in this space, they would have to share some of their intellectual property with the AC vendor, because ultimately, the AC vendor has not disclosed their proprietary protocol.=20 Again, I honestly don't see this approach as a viable one. If everyone had the exact (or close) hardware design and MAC, then this would be a possibility. Interesting point of view. Lets say a WTP vendor comes up with some unique value added feature set. The AC vendors do not support it. How does your proposal help the WTP vendor exactly? The proposal that I have been proposing would, because the AC really doesn't care how antennas or MACs are handled. It just wants access to the MAC management portion of the 802.11 protocol - which is a standard to begin with. =20 The solution is the same regardless of whether you have a control protocol or a download protocol. The WTP vendor comes up with their extensions and has a business discussion with AC vendors to support their value add. I think both proposals solve this business problem. The download protocol does this more expeditiously for the WTP vendor, the AC vendor and the customer. This assumes that vendor wants to share their intellectual property... something I don't accept so easily. Lets take your example and say a vendor decides to get out of this business (many enterprise customers are in this state now as we speak). The customer is now stuck with an expensive deployment of WTPs and ACs that are now obsolete. All the customer has to do is simply swap out the obsolete ACs with one that supports the deployed WTPs and the WLAN is back in action. The brain transplant provides investment protection to the customer assuming an enterprising AC vendor decides to take the burden of getting the installed WTPs to work with their ACs. hmmm... ok. Not sure that's what people expected for an answer. If a new WTP comes out, then one would assume that as long as it complies with the standard, it will be supported - no need to swap out AC gear.=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Mar 13 11:02:13 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19901 for ; Sun, 13 Mar 2005 11:02:12 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6F16120470; Sun, 13 Mar 2005 11:02:09 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9D5A720452; Sun, 13 Mar 2005 11:02:06 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7E17B20452 for ; Sun, 13 Mar 2005 11:01:24 -0500 (EST) Received: from huawei.com (szxga02-in.huawei.com [61.144.161.54]) by mail.frascone.com (Postfix) with ESMTP id 01AC02044C for ; Sun, 13 Mar 2005 11:01:01 -0500 (EST) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IDA00JSLSLS65@szxga02-in.huawei.com> for capwap@frascone.com; Mon, 14 Mar 2005 00:03:28 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IDA001P0SLSQ6@szxga02-in.huawei.com> for capwap@frascone.com; Mon, 14 Mar 2005 00:03:28 +0800 (CST) Received: from jys3101091805 (nsc69.38.68-97.newsouth.net [69.38.68.97]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IDA007P6SPFMF@szxml01-in.huawei.com>; Mon, 14 Mar 2005 00:06:11 +0800 (CST) From: Yao Zhong Hui To: capwap@frascone.com Cc: kempf@docomolabs-usa.com, zhouwenhui@chinamobile.com, "'Yang, Lily L'" , Saravanan Govindan , Inderpreet Singh , dorothy.gellert@nokoa.com, mmani@avaya.com Message-id: <002601c523bd$8499f300$886414ac@jys3101091805> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook Express 5.50.4927.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_FypeNHXTOxlRwHc9F2uBVg)" X-Priority: 3 X-MSMail-priority: Normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] First Things for CAPWAP protocol Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Tue, 08 Mar 2005 17:01:47 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. --Boundary_(ID_FypeNHXTOxlRwHc9F2uBVg) Content-type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7BIT Deer all, We have had two different proposals(ie. LWAPP and CTP) on CAPWAP protocol and maybe more are running to us. But I think we should clarify all CAPWAP architectural questions first. So I issue my opinions below, and would like to listen you all for any comments. (1) THE SCOPE OF CAPWAP WG We can logically divided the infrastructure into two planes: Control and management plane, and data plane. In a WLAN network, data plane is DS, and AC is a logical entity in CAPWAP context in control and management plane that act the role of centralized control and management . Figure 1 shows that one WLAN infrastructure can support multi-logical network though multi-logical DS. | | | | ++++++++ +++++++++++++++ ++++++++ + | +---------+ DS + + +----------------+ WTP + + +++++++++++++++ + AC + + | +---------+---+ + + + +--------+ ++++++++ + + DS + + ++++++++ | | + + + + | | + + + + | ++++++++ + + + + | + | +---------+ + + + +-------+ WTP + +++++++++++++++ + + | +-------------+ + ++++++++ +++++++++++++++ | Control and Management | Data Plane Plane | (Support Multi-logical user groups) | | figure 1 You also can deploy a centralized DS,and you can also release a AC device that simultaneously support both centralized DS functions and centralized control and management functions, but it is out of scope of CAPWAP WG. SO, we can get figure 2 that shows the scope of CAPWAP WG, and the interface relationship between different logical entities. Figure 2 also shows that relationship between CAPWAP WG and IEEE 802.11: CAPWAP WG only focus on Controlling and Provisioning of WTP, Don't change any WM interfaces and DSM interface. Especially don't conflict with 802.11u concerns. |------------------| | +++++++++ | | + + | | + AC + | | + + | | +++++++++ | | /|\ | | | | | (IP)| ? | | | | | \|/ | ++++++ +++++++ | +++++++++ | +++++++ + + + 802.11 | + + | ? + + + + + STA +<----------|---->+ WTP +<---|---------->+ +DS+ + + + (WM) | + + |(DSM ) +DS++++++ +++++++ | +++++++++ | +++++++ | The Scope of | | CAPWAP WG | |------------------| figure 2 Then we can focus on CAPWAP WG should concerns. (2) "WTP-to-AC" SERVICE AND "WTP-to-DS" SERVICE Generally, WTP access network by LAN, see figure 3: ++++++++ ++++++++++ ++++++++ + + Uncontrolled + + Controlled + + AC +--------------+ Switch +-------------+ Controlled Services + + Port + + Port + ++++++++ ++++++++++ ++++++++ | | | LAN | | +++++++++ + + + WTP + + + +++++++++ figure 3 But in some ISP network, ADSL access or WiMAX access is also a selection. See figure 4 below: ++++++++ +++++++++++ ++++++++ + + Uncontrolled + Accss + Controlled + + AC +--------------+ Network +-------------+ Controlled Services + + Port + + Port + ++++++++ +++++++++++ ++++++++ | | | LAN, ADSL, WiMAX, 802.11 WDM,... | | +++++++++ + + + WTP + + + +++++++++ figure 4 Figure 4 replace figure 3 "Switch" box with "Access Network" box to show a more abstract model. It is easy to do for a switch or an access network that distinguish AC and DS services through physical port, but commonly WTP only one phsical port to backhaul. So it is required that WTP can logically identify DS service flow and AC service flow with a common method that a switch and an access network can understand . If supportting logical network, WTP also required to identify different DS service flows. So I think VLAN maybe a best selection to fulfil this requirement. (3) WTP-AC i/f PROTOCOL STACK ++++++++++++++++++++++ + WTPAP + ++++++++++++++++++++++ + IP + ++++++++++++++++++++++ + Uncontrolled Port + ++++++++++++++++++++++ figure 5 I sugguest we name that CAPWAP protocol as Wirelss Terminal Point Application Protocal(WTPAP) that can show our CAPWAP WG concerns. This protocol should based on IP and require WTP to distinguish it from DS services. Thanks Zhonghui Yao --Boundary_(ID_FypeNHXTOxlRwHc9F2uBVg) Content-type: text/html; charset=gb2312 Content-Transfer-Encoding: 7BIT
Deer all,
 
We have had two different proposals(ie. LWAPP and CTP) on CAPWAP protocol and maybe more are running to us. But I think we
 
should clarify all CAPWAP architectural questions first. So I issue my opinions below, and would like to listen you all for
 
any comments. 
 
(1) THE SCOPE OF CAPWAP WG
 
We can logically divided the infrastructure into two planes: Control and management plane, and data plane. In a WLAN network,
 
data plane is DS, and AC is a logical entity in CAPWAP context in control and management plane that act the role of
 
centralized control and management . Figure 1 shows that one WLAN infrastructure can support multi-logical network though
 
multi-logical DS.
                              |
                              |
                              |         
                              |        
                           ++++++++         +++++++++++++++
   ++++++++                +  |   +---------+    DS       +
   +      +----------------+ WTP  +         +   +++++++++++++++
   +  AC  +                +  |   +---------+---+         +   +
   +      +--------+       ++++++++         +   +    DS   +   +
   ++++++++        |          |             +   +         +   +
                   |          |             +   +         +   +
                   |       ++++++++         +   +         +   +
                   |       +  |   +---------+   +         +   +
                   +-------+ WTP  +         +++++++++++++++   +
                           +  |   +-------------+             +
                           ++++++++             +++++++++++++++
                              |
  Control and Management      |            Data Plane
         Plane                |   (Support Multi-logical user groups)
                              |
                              |
 
                         figure 1
 
You also can deploy a centralized DS,and you can also release a AC device that simultaneously support both centralized DS
 
functions and centralized control and management functions, but it is out of scope of CAPWAP WG.
 
SO, we can get figure 2 that shows the scope of CAPWAP WG, and the interface relationship between different logical entities.
 
Figure 2 also shows that relationship between CAPWAP WG and IEEE 802.11: CAPWAP WG only focus on Controlling and Provisioning
 
of WTP, Don't change any WM interfaces and DSM interface. Especially don't conflict with 802.11u concerns.
 
                   |------------------|
                   |     +++++++++    |
                   |     +       +    |
                   |     +  AC   +    |
                   |     +       +    |
                   |     +++++++++    |
                   |        /|\       |
                   |         |        |
                   |     (IP)| ?      |
                   |         |        |
                   |        \|/       |              ++++++
 +++++++           |     +++++++++    |           +++++++ +
 +     +    802.11 |     +       +    |  ?        +  +  + +
 + STA +<----------|---->+  WTP  +<---|---------->+  +DS+ +
 +     +    (WM)   |     +       +    |(DSM )     +DS++++++
 +++++++           |     +++++++++    |           +++++++
                   |   The Scope of   |
                   |    CAPWAP WG     |
                   |------------------|
                        figure 2
 

Then we can focus on CAPWAP WG should concerns.
 

(2) "WTP-to-AC" SERVICE AND "WTP-to-DS" SERVICE
 
Generally, WTP access network by LAN, see figure 3:
 
     ++++++++              ++++++++++             ++++++++
     +      + Uncontrolled +        + Controlled  +
     +  AC  +--------------+ Switch +-------------+ Controlled Services            
     +      +    Port      +        +    Port     +
     ++++++++              ++++++++++             ++++++++
                                |
                                |       
                                | LAN
                                |
                                |
                            +++++++++
                            +       +
                            +  WTP  +
                            +       +
                            +++++++++
                            figure 3
 
But in some ISP network, ADSL access or WiMAX access is also a selection. See figure 4 below:
 
     ++++++++              +++++++++++             ++++++++
     +      + Uncontrolled +  Accss  +  Controlled +
     +  AC  +--------------+ Network +-------------+ Controlled Services            
     +      +    Port      +         +    Port     +
     ++++++++              +++++++++++             ++++++++
                                |
                                |
                                | LAN, ADSL, WiMAX, 802.11 WDM,...
                                |
                                |
                            +++++++++
                            +       +
                            +  WTP  +
                            +       +
                            +++++++++
                            figure 4
 
Figure 4 replace figure 3 "Switch" box with "Access Network" box to show a more abstract model. It is easy to do for a switch
 
or an access network that distinguish AC and DS services through physical port, but commonly WTP only one phsical port to
 
backhaul. So it is required that WTP can logically identify DS service flow and AC service flow with a common method that a
 
switch and an access network can understand . If supportting logical network, WTP also required to identify different DS
 
service flows. So I think VLAN maybe a best selection to fulfil this requirement.
 

(3) WTP-AC i/f PROTOCOL STACK
 
                ++++++++++++++++++++++
                +       WTPAP        +
                ++++++++++++++++++++++
                +         IP         +
                ++++++++++++++++++++++
                + Uncontrolled Port  +
                ++++++++++++++++++++++
                      figure 5
 
I sugguest we name that CAPWAP protocol as Wirelss Terminal Point Application Protocal(WTPAP) that can show our CAPWAP WG
 
concerns. This protocol should based on IP and require WTP to distinguish it from DS services.
 
 
 
Thanks
Zhonghui Yao
--Boundary_(ID_FypeNHXTOxlRwHc9F2uBVg)-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Mar 14 10:21:10 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11691 for ; Mon, 14 Mar 2005 10:21:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A22820583; Mon, 14 Mar 2005 10:21:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7CF7220573; Mon, 14 Mar 2005 10:21:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9B8D420573 for ; Mon, 14 Mar 2005 10:21:00 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 71E182055E for ; Mon, 14 Mar 2005 10:20:57 -0500 (EST) Received: from Palpatine ([10.81.114.236]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j2EFH7vO021892; Mon, 14 Mar 2005 23:17:23 +0800 (SGT) From: "Cheng Hong" To: "'Dan Harkins'" , "'Paul Lambert'" Cc: "'Keerti Melkote'" , "'Pat R. Calhoun'" , Subject: RE: [Capwap] A simpler approach to CAPWAP Organization: Panasonic Singapore Laboratories Message-ID: <00ab01c528a9$6522f120$ec72510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <200503112050.j2BKo4MY012763@homebrew.trpz.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 14 Mar 2005 23:20:27 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Dan > Put yourself in that place. Your chipset has some > whippy-dippy feature that no one else's has but the > "standard" doesn't allow for control or management of it. Whaddya do? Please note that the extensibilty is also one of the objective inlcuded in the draft. If a new feature needs to be supported, some extension could be created, and published. AC or WTP vender that wants to support that feature could just inlcue the extension if they want. This has nothing different from that RADIUS or Diameter is doing. This is much easier than asking WTP vendor go to all the AC vendors to have that feature incorporated into the new image. I guess the pure "brain transplant" method will make the problem of matching 1:n permutations into matching n:n permutations. cheers Cheng > -----Original Message----- > From: capwap-admin@frascone.com > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > Sent: Saturday, March 12, 2005 4:50 AM > To: Paul Lambert > Cc: Keerti Melkote; Pat R. Calhoun; capwap@frascone.com > Subject: Re: [Capwap] A simpler approach to CAPWAP > > > Paul, > > I don't want to get into a symantic game about whose > private definition of the word "proprietary" is more correct > but something here deserves a comment. > > On Fri, 11 Mar 2005 12:06:30 PST you wrote > > > > If I'm an AC vendor, I can only field a 'brain transplant' > if I have a > > very close relationship with the WTP vendor. The relationship must > > either include full documentation of the WTP hardware > interfaces, OS > > and board level information for the AC vendor to write > code, or a full > > set of protocol signaling that includes the data encapsulation > > techniques and control signaling. > > You're right. The relationship would probably include all the > information necessary for an AC vendor to port his code to a > WTP vendor's platform. Contrary examples exist (netbsd runs > on a playstation2) but that is, as you have pointed out, not "easy". > > Or, you say, "a full set of protocol signaling that includes > the data encapsulation techniques and control signalling." > That's exactly why the all-encompasing control plane and data > encapsulation option is so unappealing. Either your set is > the same as everyone else's set (in which case it wouldn't > appear in your argument so let's just dismiss that fiction > immediately) or something in someone's set of control > signaling-- perhaps your's!-- is going to be left out of the > "standard". > > Put yourself in that place. Your chipset has some > whippy-dippy feature that no one else's has but the > "standard" doesn't allow for control or management of it. Whaddya do? > > Dan. > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Mar 14 10:50:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15755 for ; Mon, 14 Mar 2005 10:50:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 329A9205A2; Mon, 14 Mar 2005 10:50:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 639532058D; Mon, 14 Mar 2005 10:50:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61DFC2058A for ; Mon, 14 Mar 2005 10:49:25 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 043E020576 for ; Mon, 14 Mar 2005 10:49:22 -0500 (EST) Received: from Palpatine ([10.81.114.236]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j2EFik1o022164; Mon, 14 Mar 2005 23:44:57 +0800 (SGT) From: "Cheng Hong" To: "'Keerti Melkote'" , "'Mani, Mahalingam (Mahalingam)'" Cc: "'Pat R. Calhoun'" , Subject: RE: [Capwap] A simpler approach to CAPWAP Organization: Panasonic Singapore Laboratories Message-ID: <00ac01c528ad$3f2527a0$ec72510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 14 Mar 2005 23:48:07 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Keerti, Not sure how this single download protocl helps to achieve = interoperability. It seems that the AC and WTP vendors need to have certain private arrangement (anyway, the AC vendors builts the image to be run by the = WTP). Then, what prevents them to go one step further to negotiate their own downloading procedures. Couldn't see the need for a standard here. I = guess it has been discussed long time back in this mailing list, and probably = that is why it is decided out of problem scope of the current WG. The CAPWAP = is introduced to obviate the direct relationship between WTP vendors and AC vendors. The downloading method obviously dosen't meet this goal. cheers Cheng =20 > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of Keerti Melkote > Sent: Saturday, March 12, 2005 4:23 AM > To: Mani, Mahalingam (Mahalingam) > Cc: Pat R. Calhoun; capwap@frascone.com > Subject: Re: [Capwap] A simpler approach to CAPWAP >=20 >=20 > Mani, >=20 > See inline. >=20 > -Keerti >=20 >=20 > On Fri, 11 Mar 2005 13:00:02 -0700, Mani, Mahalingam=20 > (Mahalingam) wrote: > > Keerti, > >=20 > > See inline. > >=20 > > -mani > > =3D=3D=3D=3D=3D=3D > >=20 > > [...] > > > > >=20 > > You ruling something out, means nothing to me. I am=20 > disappointed that=20 > > the chairs fail to recognize the real issues and continue to pursue=20 > > academic objectives without regard to market realities. > >=20 > > [Mani, Mahalingam (Mahalingam)] this is not an academic=20 > objective. If=20 > > it turns out to achieve something in the academic realm as=20 > well - I am=20 > > sure the erudite ones in the WG will be glad to have contributed. > >=20 > > The chairs have no intentions to tolerate proposals that make a=20 > > mockery of IETF or CAPWAP objectives and charter. > >=20 >=20 > If questioning objectives is a mockery of the IETF or =20 > CAPWAP, then I fail to see how this is in the spirit of open=20 > debate which the IETF has always stood for. >=20 > The fact remains that there is not a single substantive=20 > argument which says a download protocol does not meet the=20 > market objective of interoperability between ACs and WTPs.=20 > The arguments seem to center around the fact that the method=20 > of communication seem proprietary but never the fact that an=20 > AC and a WTP from different vendors can be made interoperable. >=20 > However, we continue to proceed without accepting this as an=20 > alternative to the heavy duty protocols that have been=20 > submitted today. I agree that it does not deliver=20 > interoperability of the kind this group seems to prefer. But=20 > customers are NOT asking for this. They are asking for=20 > interoperability. Full Stop. Not of a specific kind. >=20 > > Nor proposals for the sake of one. > >=20 > > Nor to detract from charter goals the WG has shown consensus=20 > > (including the current proponent-s) on; while still being open to=20 > > arguments on serious validation issues, if any, including=20 > the charter;=20 > > this will require more than mere assertions. > >=20 > > I would urge, finally, to keep the debate, discussions and=20 > objective=20 > > statements focusing on problems and/or issues at hand and not mix=20 > > unjustifiable rhetoric. > >=20 > > > As an AC vendor, the last thing that I really want to do=20 > is to have=20 > > > to > > [Mani, Mahalingam (Mahalingam)] [...] > >=20 > > Keerti Melkote > > Founder > > Aruba Networks > >=20 > > > Pat R Calhoun > > > CTO/Founder > > > Airespace, Inc. > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com=20 > http://mail.frascone.com/mailman/listinfo/capwap > > > > > [Mani, Mahalingam (Mahalingam)] -mani=20 > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > >=20 > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap >=20 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Mar 14 12:12:12 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24117 for ; Mon, 14 Mar 2005 12:12:11 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E9E02205B5; Mon, 14 Mar 2005 12:12:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 90333205A2; Mon, 14 Mar 2005 12:12:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 12C53205A2 for ; Mon, 14 Mar 2005 12:11:28 -0500 (EST) Received: from homebrew.trpz.com (66-7-225-40.cust.telepacific.net [66.7.225.40]) by mail.frascone.com (Postfix) with ESMTP id 3ABB120597 for ; Mon, 14 Mar 2005 12:11:24 -0500 (EST) Received: from trpz.com (localhost.trpz.com [127.0.0.1]) by homebrew.trpz.com (8.13.1/8.13.1) with ESMTP id j2EH98ql023685; Mon, 14 Mar 2005 09:09:08 -0800 (PST) (envelope-from dharkins@trpz.com) Message-Id: <200503141709.j2EH98ql023685@homebrew.trpz.com> To: "Cheng Hong" Cc: "'Paul Lambert'" , "'Keerti Melkote'" , "'Pat R. Calhoun'" , capwap@frascone.com Subject: Re: [Capwap] A simpler approach to CAPWAP In-Reply-To: Your message of "Mon, 14 Mar 2005 23:20:27 +0800." <00ab01c528a9$6522f120$ec72510a@Palpatine> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23683.1110820148.1@trpz.com> From: Dan Harkins X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 14 Mar 2005 09:09:08 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) RADIUS is a bad example. How long did it take to get RFC3580 out the door? Because of this problem what people do is come up with VSAs. Talk about a n:n problem! You'll have to know what set of proprietary extensions each WTP vendor has added to this "standard" protocol. Dan. On Mon, 14 Mar 2005 23:20:27 +0800 you wrote > Hi Dan > > > Put yourself in that place. Your chipset has some > > whippy-dippy feature that no one else's has but the > > "standard" doesn't allow for control or management of it. Whaddya do? > > Please note that the extensibilty is also one of the objective inlcuded in > the draft. If a new feature needs to be supported, some extension could be > created, and published. AC or WTP vender that wants to support that feature > could just inlcue the extension if they want. This has nothing different > from that RADIUS or Diameter is doing. > > This is much easier than asking WTP vendor go to all the AC vendors to have > that feature incorporated into the new image. I guess the pure "brain > transplant" method will make the problem of matching 1:n permutations into > matching n:n permutations. > > cheers > > Cheng > > > -----Original Message----- > > From: capwap-admin@frascone.com > > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > > Sent: Saturday, March 12, 2005 4:50 AM > > To: Paul Lambert > > Cc: Keerti Melkote; Pat R. Calhoun; capwap@frascone.com > > Subject: Re: [Capwap] A simpler approach to CAPWAP > > > > > > Paul, > > > > I don't want to get into a symantic game about whose > > private definition of the word "proprietary" is more correct > > but something here deserves a comment. > > > > On Fri, 11 Mar 2005 12:06:30 PST you wrote > > > > > > If I'm an AC vendor, I can only field a 'brain transplant' > > if I have a > > > very close relationship with the WTP vendor. The relationship must > > > either include full documentation of the WTP hardware > > interfaces, OS > > > and board level information for the AC vendor to write > > code, or a full > > > set of protocol signaling that includes the data encapsulation > > > techniques and control signaling. > > > > You're right. The relationship would probably include all the > > information necessary for an AC vendor to port his code to a > > WTP vendor's platform. Contrary examples exist (netbsd runs > > on a playstation2) but that is, as you have pointed out, not "easy". > > > > Or, you say, "a full set of protocol signaling that includes > > the data encapsulation techniques and control signalling." > > That's exactly why the all-encompasing control plane and data > > encapsulation option is so unappealing. Either your set is > > the same as everyone else's set (in which case it wouldn't > > appear in your argument so let's just dismiss that fiction > > immediately) or something in someone's set of control > > signaling-- perhaps your's!-- is going to be left out of the > > "standard". > > > > Put yourself in that place. Your chipset has some > > whippy-dippy feature that no one else's has but the > > "standard" doesn't allow for control or management of it. Whaddya do? > > > > Dan. > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Mar 14 16:51:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25781 for ; Mon, 14 Mar 2005 16:51:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BEF9A20263; Mon, 14 Mar 2005 16:51:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 224FA1FF1F; Mon, 14 Mar 2005 16:51:06 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A8771FF1F for ; Mon, 14 Mar 2005 16:50:56 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id CAC6E1FE11 for ; Mon, 14 Mar 2005 16:50:54 -0500 (EST) Message-ID: <013601c528e0$0be8f910$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Keerti Melkote" , "Mani, Mahalingam (Mahalingam)" Cc: "Pat R. Calhoun" , References: Subject: Re: [Capwap] A simpler approach to CAPWAP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 14 Mar 2005 13:51:52 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Keerti, > The fact remains that there is not a single substantive argument which > says a download protocol does not meet the market objective of > interoperability between ACs and WTPs. The arguments seem to center > around the fact that the method of communication seem proprietary but > never the fact that an AC and a WTP from different vendors can be made > interoperable. > I believe several postings have raised the issue about whether a broad set of interoperable WTPs and ACs could be achieved using this technique. The primary arguments have involved the degree to which the WTP and AC vendors need to know the details of each other's hardware, and the tendency thereby for WTP and AC vendors to drift into islands of interoperability where the relevent NDAs and such are signed. Thus, a download protocol might be more likely to lead to proprietary vendor-lock in, since a service provider would need to select a particular island and stick with it, rather than be able to choose from a broad variety of interoperable vendors as is the case with most other networking gear today. > However, we continue to proceed without accepting this as an alternative to the > heavy duty protocols that have been submitted today. I agree that it > does not deliver interoperability of the kind this group seems to > prefer. But customers are NOT asking for this. They are asking for > interoperability. Full Stop. Not of a specific kind. > I can't claim to be a customer of Aruba, and, as in all matters IETF, I speak as an individual, but since I work for a wireless service provider, I believe I have some insight into what's in the best interest of wireless service providers, who are or will ultimately be customers of AC and WTP vendors. I believe an interoperable WLAN RAN protocol is clearly to the benefit of wireless service providers. Interoperable protocols (what ultimately IETF is all about) have proven time and again to benefit customers of networking gear, and I don't see any indications that this is any different. In fact, as I've mentioned before on this thread, the entire situation is very reminiscent of the time about 8-10 years ago when 3GPP standardized the UMTS RAN protocols. The RAN protocol in GSM was not standardized, and wireless service providers insisted on standardizing it in 3G. Today, it is possible to set up a multi-vendor UMTS RAN, whereas that was not the case with GSM.* jak *In fact, I believe it is now also possible to set up a multivendor GSM RAN, since 3GPP approved the new GERAN protocol standard. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Mar 14 20:11:07 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15531 for ; Mon, 14 Mar 2005 20:11:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BCC0F2041D; Mon, 14 Mar 2005 20:11:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 51B232038D; Mon, 14 Mar 2005 20:11:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 212E72038D for ; Mon, 14 Mar 2005 20:10:45 -0500 (EST) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by mail.frascone.com (Postfix) with ESMTP id 6CDDE2037F for ; Mon, 14 Mar 2005 20:10:43 -0500 (EST) Received: from Matt-Holdrege.verizon.net ([208.179.69.254]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IDD00D65CLOQE50@vms046.mailsrvcs.net> for capwap@frascone.com; Mon, 14 Mar 2005 19:10:42 -0600 (CST) From: Matt Holdrege Subject: Re: [Capwap] A simpler approach to CAPWAP In-reply-to: <200503141709.j2EH98ql023685@homebrew.trpz.com> X-Sender: res06gzk@incoming.verizon.net To: Dan Harkins Cc: capwap@frascone.com Message-id: <6.1.2.0.2.20050314170816.021bb940@incoming.verizon.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Content-type: text/plain; charset=us-ascii; format=flowed References: <200503141709.j2EH98ql023685@homebrew.trpz.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 14 Mar 2005 17:11:52 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) There is no shortage of bad things to say about RADIUS and many have done just that over the years on WG email lists. However you can't say it hasn't been wildly successful for service providers. They absolutely love it. Would they switch if something better came along? Yes. Has anything better come along? No. Sorry to digress, but maybe this has a bit of relevance? -Matt At 09:09 AM 3/14/2005, Dan Harkins wrote: > RADIUS is a bad example. How long did it take to get RFC3580 out >the door? Because of this problem what people do is come up with >VSAs. Talk about a n:n problem! You'll have to know what set of >proprietary extensions each WTP vendor has added to this "standard" >protocol. > > Dan. > >On Mon, 14 Mar 2005 23:20:27 +0800 you wrote > > Hi Dan > > > > > Put yourself in that place. Your chipset has some > > > whippy-dippy feature that no one else's has but the > > > "standard" doesn't allow for control or management of it. Whaddya do? > > > > Please note that the extensibilty is also one of the objective inlcuded in > > the draft. If a new feature needs to be supported, some extension could be > > created, and published. AC or WTP vender that wants to support that feature > > could just inlcue the extension if they want. This has nothing different > > from that RADIUS or Diameter is doing. > > > > This is much easier than asking WTP vendor go to all the AC vendors to have > > that feature incorporated into the new image. I guess the pure "brain > > transplant" method will make the problem of matching 1:n permutations into > > matching n:n permutations. > > > > cheers > > > > Cheng > > > > > -----Original Message----- > > > From: capwap-admin@frascone.com > > > [mailto:capwap-admin@frascone.com] On Behalf Of Dan Harkins > > > Sent: Saturday, March 12, 2005 4:50 AM > > > To: Paul Lambert > > > Cc: Keerti Melkote; Pat R. Calhoun; capwap@frascone.com > > > Subject: Re: [Capwap] A simpler approach to CAPWAP > > > > > > > > > Paul, > > > > > > I don't want to get into a symantic game about whose > > > private definition of the word "proprietary" is more correct > > > but something here deserves a comment. > > > > > > On Fri, 11 Mar 2005 12:06:30 PST you wrote > > > > > > > > If I'm an AC vendor, I can only field a 'brain transplant' > > > if I have a > > > > very close relationship with the WTP vendor. The relationship must > > > > either include full documentation of the WTP hardware > > > interfaces, OS > > > > and board level information for the AC vendor to write > > > code, or a full > > > > set of protocol signaling that includes the data encapsulation > > > > techniques and control signaling. > > > > > > You're right. The relationship would probably include all the > > > information necessary for an AC vendor to port his code to a > > > WTP vendor's platform. Contrary examples exist (netbsd runs > > > on a playstation2) but that is, as you have pointed out, not "easy". > > > > > > Or, you say, "a full set of protocol signaling that includes > > > the data encapsulation techniques and control signalling." > > > That's exactly why the all-encompasing control plane and data > > > encapsulation option is so unappealing. Either your set is > > > the same as everyone else's set (in which case it wouldn't > > > appear in your argument so let's just dismiss that fiction > > > immediately) or something in someone's set of control > > > signaling-- perhaps your's!-- is going to be left out of the > > > "standard". > > > > > > Put yourself in that place. Your chipset has some > > > whippy-dippy feature that no one else's has but the > > > "standard" doesn't allow for control or management of it. Whaddya do? > > > > > > Dan. > > > > > > _______________________________________________ > > > Capwap mailing list > > > Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap > > > > > > > > > > > > _______________________________________________ > > Capwap mailing list > > Capwap@frascone.com > > http://mail.frascone.com/mailman/listinfo/capwap >_______________________________________________ >Capwap mailing list >Capwap@frascone.com >http://mail.frascone.com/mailman/listinfo/capwap _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Mar 21 15:31:09 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14980 for ; Mon, 21 Mar 2005 15:31:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 35C2520510; Mon, 21 Mar 2005 15:31:09 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 82FDF204E8; Mon, 21 Mar 2005 15:31:06 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ED43B204E8 for ; Mon, 21 Mar 2005 15:30:59 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 0F86420467 for ; Mon, 21 Mar 2005 15:30:57 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14966; Mon, 21 Mar 2005 15:30:54 -0500 (EST) Message-Id: <200503212030.PAA14966@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: capwap@frascone.com From: Internet-Drafts@ietf.org X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] I-D ACTION:draft-ietf-capwap-objectives-01.txt Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Mon, 21 Mar 2005 15:30:54 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Control And Provisioning of Wireless Access Points Working Group of the IETF. Title : Objectives for Control and Provisioning of Wireless Access Points (CAPWAP) Author(s) : S. Govindan, et al. Filename : draft-ietf-capwap-objectives-01.txt Pages : 30 Date : 2005-3-21 This document presents objectives for an interoperable protocol for the Control and Provisioning of Wireless Access Points (CAPWAP). The document aims to establish a set of focused requirements for the development and evaluation of a CAPWAP protocol. The objectives address Architecture, Operation, Security and Network Operator Requirements that are necessary to enable interoperability among wireless local area network (WLAN) devices of alternative designs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-capwap-objectives-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-capwap-objectives-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-capwap-objectives-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-21154210.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-capwap-objectives-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-capwap-objectives-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-21154210.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From motsuk@doneasy.com Wed Mar 23 22:22:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26542; Wed, 23 Mar 2005 22:22:19 -0500 (EST) Received: from 66.169.172.153.ts46v-13.otng1.ftwrth.tx.charter.com ([66.169.172.153]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DEJ0v-0001fb-7M; Wed, 23 Mar 2005 22:28:08 -0500 X-Apparently-To: bridge-mib-admin@ietf.org X-Sieve: CMU Sieve 2.2 Received: from button.inherent.pochta.ru ([unix socket]) by pinnacle.mallard.pochta.ru (Cyrus v2.2.6) with LMTPA; Thu, 24 Mar 2005 06:24:10 +0300 Date: Thu, 24 Mar 2005 09:17:10 +0600 From: "Ryan Banks" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: bridge-mib-admin@ietf.org Cc: business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org Subject: Notification: We offer low rates X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 5.4 (+++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.ok-mrg-now.com/nowss.asp Best Regards, Roslyn Morris to be remov(ed: http://www.ok-mrg-now.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From arier@yebox.com Thu Mar 24 01:55:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15529 for ; Thu, 24 Mar 2005 01:55:59 -0500 (EST) Received: from cpe000ae6ae6f68-cm0f1119821344.cpe.net.cable.rogers.com ([24.102.50.120]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DEMLk-00080v-6J for capwap-archive@ietf.org; Thu, 24 Mar 2005 02:01:49 -0500 X-Apparently-To: business@ietf.org X-Sieve: CMU Sieve 2.2 Received: from fugitive.backstage.pochta.ru ([unix socket]) by crockett.casbah.pochta.ru (Cyrus v2.2.2) with LMTPA; Thu, 24 Mar 2005 00:52:54 -0600 Date: Thu, 24 Mar 2005 10:51:54 +0400 From: "Lou Foote" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: business@ietf.org Cc: calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org Subject: High rates? Not with us! low fixed rate X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 2.9 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.ok-mrg-now.com/nowss.asp Best Regards, Gretchen Moody to be remov(ed: http://www.ok-mrg-now.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From baroue@emailaccount.com Fri Mar 25 05:34:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09868; Fri, 25 Mar 2005 05:34:01 -0500 (EST) Received: from 205.red-81-184-43.user.auna.net ([81.184.43.205]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DEmEW-0002V7-0I; Fri, 25 Mar 2005 05:40:07 -0500 Authentication-Results: tried.es from=premium.bladder.es; domainkeys=neutral (no sig) X-Originating-IP: [34.96.124.40] Received: from premium.acquit.es (EHLO premium.backstage.es) by premium.homemade.es with SMTP; Fri, 25 Mar 2005 08:26:54 -0200 Date: Fri, 25 Mar 2005 05:24:54 -0500 From: "Freda Dye" To: bmwg@ietf.org Cc: bmwg-admin@ietf.org, bmwg-archive@ietf.org, bofchairs@ietf.org, bounces-ietf@ietf.org, bpana@ietf.org, brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org Subject: You've been selected for a low rate Message-ID: <116641.5732.baroue@emailaccount.com> X-Mailer: Kana Connect 6 X-Spam-Score: 12.0 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.ok-ref-yes.net/nowss.asp Best Regards, Lucille Kramer to be remov(ed: http://www.ok-ref-yes.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From oraski@mailAccount.com Fri Mar 25 08:49:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27649; Fri, 25 Mar 2005 08:49:26 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEpHe-0008N2-2E; Fri, 25 Mar 2005 08:55:33 -0500 Received: from [82.240.0.48] (helo=testv2-82-240-0-48.fbx.proxad.net) by mx2.foretec.com with smtp (Exim 4.24) id 1DEpBj-0006Re-42; Fri, 25 Mar 2005 08:49:23 -0500 Authentication-Results: redmond.es from=premium.rex.es; domainkeys=neutral (no sig) X-Originating-IP: [46.176.100.132] Received: from premium.cholinesterase.es (EHLO premium.starling.es) by premium.tenon.es with SMTP; Fri, 25 Mar 2005 12:46:14 -0100 Date: Fri, 25 Mar 2005 09:45:14 -0400 From: "Hiram Mccall" To: bmwg@ietf.org Cc: bmwg-admin@ietf.org, bmwg-archive@ietf.org, bofchairs@ietf.org, bounces-ietf@ietf.org, bpana@ietf.org, brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org Subject: Approved mortage rate Message-ID: <114441.1707.oraski@mailAccount.com> X-Mailer: Kana Connect 6 X-Spam-Score: 2.2 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.ok-ref-yes.net/nowss.asp Best Regards, Jonathan Myers to be remov(ed: http://www.ok-ref-yes.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From laffeyt@didamail.com Sat Mar 26 08:31:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26440 for ; Sat, 26 Mar 2005 08:31:34 -0500 (EST) Received: from d084164.adsl.hansenet.de ([80.171.84.164]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DFBU7-00063M-Ga for capwap-archive@ietf.org; Sat, 26 Mar 2005 08:37:53 -0500 Received: from board.vinson-sterling.com (HELO fantasy.com 66.1.189.19) by gallus.com with EMQP; Sat, 26 Mar 2005 07:25:21 -0600 Date: Sat, 26 Mar 2005 18:31:21 +0500 From: "Milagros Reece" Message-Id: To: business@ietf.org Cc: calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org Subject: Notification: We offer low rates X-Mailer: CompuServe 7.0 X-Spam-Score: 2.6 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.ok-ref-yes.net/nowss.asp Best Regards, Garth Landers to be remov(ed: http://www.ok-ref-yes.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From shibah@emailaccount.com Sun Mar 27 02:08:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20037 for ; Sun, 27 Mar 2005 02:08:31 -0500 (EST) Received: from 175.red-62-57-219.user.auna.net ([62.57.219.175]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DFRz9-0006C4-3V for capwap-archive@ietf.org; Sun, 27 Mar 2005 02:14:59 -0500 X-Apparently-To: cancer@ietf.org X-Sieve: CMU Sieve 2.2 Received: from ellison.excerpt.pochta.ru ([unix socket]) by ebony.stahl.pochta.ru (Cyrus v2.2.2) with LMTPA; Sun, 27 Mar 2005 12:04:27 +0500 Date: Sun, 27 Mar 2005 06:05:27 -0100 From: "Tad Minor" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: cancer@ietf.org Cc: capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org Subject: You've been selected for a low rate X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.forever-mrt-now.net/nowss.asp Best Regards, Lloyd Swartz to be remov(ed: http://www.forever-mrt-now.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From stites@doneasy.com Sun Mar 27 02:45:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05303; Sun, 27 Mar 2005 02:45:15 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFSYh-0007Nq-8Q; Sun, 27 Mar 2005 02:51:44 -0500 Received: from 113-10-240.adsl.cust.tie.cl ([200.113.10.240]) by mx2.foretec.com with smtp (Exim 4.24) id 1DFSSQ-0000jo-7J; Sun, 27 Mar 2005 02:45:14 -0500 Authentication-Results: elision.es from=premium.blatz.es; domainkeys=neutral (no sig) X-Originating-IP: [29.24.212.236] Received: from premium.canvasback.es (EHLO premium.obese.es) by premium.between.es with SMTP; Sun, 27 Mar 2005 09:41:54 +0200 Date: Sun, 27 Mar 2005 10:44:54 +0300 From: "Isiah Fitzpatrick" To: bmwg@ietf.org Cc: bmwg-admin@ietf.org, bmwg-archive@ietf.org, bofchairs@ietf.org, bounces-ietf@ietf.org, bpana@ietf.org, brenton.daniels@ietf.org, bridge-mib@ietf.org, bridge-mib-admin@ietf.org, business@ietf.org, calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org Subject: Lowest rates in 45 years Message-ID: <112141.8452.stites@doneasy.com> X-Mailer: Kana Connect 6 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.forever-mrt-now.net/nowss.asp Best Regards, Terrance Wall to be remov(ed: http://www.forever-mrt-now.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From swarm@yebox.com Sun Mar 27 03:53:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09252 for ; Sun, 27 Mar 2005 03:53:41 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFTcx-0000x0-L4 for capwap-archive@ietf.org; Sun, 27 Mar 2005 04:00:11 -0500 Received: from 200-204-33-202.dsl.telesp.net.br ([200.204.33.202]) by mx2.foretec.com with smtp (Exim 4.24) id 1DFTWd-00024X-JL for capwap-archive@ietf.org; Sun, 27 Mar 2005 03:53:43 -0500 Received: from frustrater-jcoppens.com (EHLO inhabitation.jcoppens.com) by custodian.jcoppens.com with SMTP; Sun, 27 Mar 2005 01:47:16 -0700 Date: Sun, 27 Mar 2005 02:54:16 -0600 From: "Eldon Eldridge" To: calsch@ietf.org Cc: cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org Subject: Approved mortage rate Message-ID: X-SpamTest-Info: Profile: SysLog X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [629], SpamtestISP/Release X-Mailer: MIME-tools 5.41 (Entity 5.404) X-Spam-Score: 2.4 (++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.forever-mrt-now.net/nowss.asp Best Regards, Dennis Pace to be remov(ed: http://www.forever-mrt-now.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From issuant@didamail.com Tue Mar 29 10:12:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06553 for ; Tue, 29 Mar 2005 10:12:57 -0500 (EST) Received: from [60.233.186.138] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DGIVU-0007oH-Ng for capwap-archive@ietf.org; Tue, 29 Mar 2005 10:19:56 -0500 Received: from adjoint.insomnia-irredentism.com (HELO tend.com 66.9.148.89) by granddaughter.com with EMQP; Tue, 29 Mar 2005 09:11:38 -0600 Date: Tue, 29 Mar 2005 11:08:38 -0400 From: "Tammi Moreno" Message-Id: To: capwap-archive@ietf.org Cc: ccips@ietf.org, cclark@ietf.org Subject: Rates fixed X-Mailer: CompuServe 7.0 X-Spam-Score: 16.5 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.go-mrt-now.com/sign.asp Best Regards, Marcy Parks to be remov(ed: http://www.go-mrt-now.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From burghart@yebox.com Tue Mar 29 11:06:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14280 for ; Tue, 29 Mar 2005 11:06:11 -0500 (EST) Received: from cc813831-a.ensch1.ov.home.nl ([217.123.145.79]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DGJL1-0001hs-GW for capwap-archive@ietf.org; Tue, 29 Mar 2005 11:13:09 -0500 X-Apparently-To: capwap-archive@ietf.org X-Sieve: CMU Sieve 2.2 Received: from clitoris.lavoisier.pochta.ru ([unix socket]) by statistician.helium.pochta.ru (Cyrus v2.2.9) with LMTPA; Tue, 29 Mar 2005 20:08:39 +0400 Date: Tue, 29 Mar 2005 17:03:39 +0100 From: "Ericka Wynn" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: capwap-archive@ietf.org Cc: ccips@ietf.org, cclark@ietf.org Subject: High rates? Not with us! low fixed rate X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 6.2 (++++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.go-mrt-now.com/sign.asp Best Regards, Hollie Bonner to be remov(ed: http://www.go-mrt-now.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From thress@doneasy.com Tue Mar 29 11:15:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16938 for ; Tue, 29 Mar 2005 11:15:45 -0500 (EST) Received: from 193.red-83-42-60.pooles.rima-tde.net ([83.42.60.193]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DGJUE-0002a7-VF for capwap-archive@ietf.org; Tue, 29 Mar 2005 11:22:45 -0500 Received: from compagnie.concur-coolheaded.com (HELO goldfinch.com 66.4.145.67) by degrease.com with EMQP; Tue, 29 Mar 2005 21:08:07 +0500 Date: Tue, 29 Mar 2005 20:14:07 +0400 From: "Iva Walker" Message-Id: To: capwap-archive@ietf.org Cc: ccips@ietf.org, cclark@ietf.org Subject: Save hundreds every month on low rates X-Mailer: CompuServe 7.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.go-mrt-now.com/sign.asp Best Regards, Bart May to be remov(ed: http://www.go-mrt-now.com/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From capwap-admin@frascone.com Thu Mar 31 09:45:12 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27079 for ; Thu, 31 Mar 2005 09:45:11 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4F8A32057C; Thu, 31 Mar 2005 09:45:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B91FD20573; Thu, 31 Mar 2005 09:45:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50A712056A for ; Thu, 31 Mar 2005 09:44:51 -0500 (EST) Received: from hotmail.com (bay20-f26.bay20.hotmail.com [64.4.54.115]) by mail.frascone.com (Postfix) with ESMTP id 7162020566 for ; Thu, 31 Mar 2005 09:44:48 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 31 Mar 2005 06:44:48 -0800 Message-ID: Received: from 202.156.2.218 by by20fd.bay20.hotmail.msn.com with HTTP; Thu, 31 Mar 2005 14:44:47 GMT X-Originating-IP: [202.156.2.218] X-Originating-Email: [saravanang@hotmail.com] X-Sender: saravanang@hotmail.com From: "Saravanan Govindan" To: capwap@frascone.com Cc: hcheng@psl.com.sg, iino.satoshi@jp.panasonic.com, sugiura.mikihito@jp.panasonic.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 31 Mar 2005 14:44:48.0039 (UTC) FILETIME=[2FD62370:01C53600] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Wireless LAN Control Protocol (WiCoP) Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 31 Mar 2005 22:44:47 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Dear All, We have submitted a draft on the Wireless LAN Control Protocol (WiCoP). WiCoP addresses local-MAC & split-MAC co-existence together with shared WLAN deployments. The abstract: The popularity of wireless local area networks (WLANs) has led to wide spread deployments across different establishments. It has also translated in to increasing scale of the WLANs. Large-scale deployments made of large numbers of wireless termination points (WTPs) and covering substantial areas are increasingly common. The Wireless LAN Control Protocol (WiCoP) described in this document allows for the control and provisioning of large-scale WLANs. It enables central management of these networks and realizes the objectives set forth for the control and provisioning of wireless access points (CAPWAP). The full draft is available from; http://www.psl.com.sg/internet-drafts/draft-iino-capwap-wicop-00.txt Cheers, Saravanan _________________________________________________________________ Keep track of Singapore & Malaysia stock prices. http://www.msn.com.sg/money/ _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From chondre@doneasy.com Thu Mar 31 10:39:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04410 for ; Thu, 31 Mar 2005 10:39:01 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH1sE-0003AX-3r for capwap-archive@ietf.org; Thu, 31 Mar 2005 10:46:26 -0500 Received: from [222.234.14.236] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DH1l2-0000q2-J1 for capwap-archive@ietf.org; Thu, 31 Mar 2005 10:38:57 -0500 X-Apparently-To: business@ietf.org X-Sieve: CMU Sieve 2.2 Received: from quantitative.ace.pochta.ru ([unix socket]) by barb.collude.pochta.ru (Cyrus v2.2.3) with LMTPA; Thu, 31 Mar 2005 18:36:03 +0300 Date: Thu, 31 Mar 2005 20:37:03 +0500 From: "Lucille Gustafson" Message-Id: X-Accept-Language: en,zh-TW,zh-CN,zh,ja,ko,tr,ru To: business@ietf.org Cc: calsch@ietf.org, cancer@ietf.org, capwap-archive@ietf.org, ccips@ietf.org, cclark@ietf.org Subject: Lowest rates in 45 years X-Mailer: Forte Agent 1.91/32.564 X-Spam-Score: 5.6 (+++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hello, We tried contacting you awhile ago about your low interest morta(ge rate. You have qualified for the lowest rate in years... You could get over $380,000 for as little as $500 a month! Ba(d credit? Doesn't matter, low rates are fixed no matter what! To get a free, no obli,gation consultation click below: http://www.now-and-forever.net/sign.asp Best Regards, Phil Ochoa to be remov(ed: http://www.now-and-forever.net/gone.asp this process takes one week, so please be patient. we do our best to take your email/s off but you have to fill out a rem/ove or else you will continue to recieve email/s. From capwap-admin@frascone.com Thu Mar 31 18:19:08 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23167 for ; Thu, 31 Mar 2005 18:19:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E7A4C2053C; Thu, 31 Mar 2005 18:19:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 81CCF2052C; Thu, 31 Mar 2005 18:19:05 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB3FC2052C for ; Thu, 31 Mar 2005 18:18:14 -0500 (EST) Received: from aruba-server.arubanetworks.com (smtp.arubanetworks.com [216.31.249.252]) by mail.frascone.com (Postfix) with SMTP id DA51B2051A for ; Thu, 31 Mar 2005 18:18:12 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: new draft submission Thread-Index: AcU2R+eqzvFkNHOKR+yehscFXaxwsw== From: "Partha Narasimhan" To: Cc: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] new draft submission Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 31 Mar 2005 15:18:10 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable All, Dan Harkins and I are submitting a new draft to the CAPWAP WG. The draft = can be accessed immediately from http://www.arubanetworks.com/technology/draft-narasimhan-ietf-slapp-01.tx= t while it flows through the usual process.=20 Please post your comments to the mailing list. Thanks partha _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Mar 31 19:58:04 2005 Received: from mail.frascone.com (postfix@frascone.com [204.49.99.9]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01084 for ; Thu, 31 Mar 2005 19:58:03 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5E86020551; Thu, 31 Mar 2005 19:58:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1C9F120543; Thu, 31 Mar 2005 19:58:03 -0500 (EST) X-Original-To: capwap@frascone.com Delivered-To: capwap@frascone.com Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B42E520543 for ; Thu, 31 Mar 2005 19:57:01 -0500 (EST) Received: from AIREMAIL.airespace.com (mail.airespace.com [66.236.111.57]) by mail.frascone.com (Postfix) with ESMTP id D31442053E for ; Thu, 31 Mar 2005 19:56:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53655.ADDDB16D" Message-ID: <526F1C0D08561F4BB79022CB938A068B09AEE1@AIREMAIL.airespace.com> Thread-Topic: draft-ohara-capwap-lwapp-02.txt has been submitted Thread-Index: AcU2Va1tzaVUrnncSF23a2aNc2YQ6A== From: "Pat R. Calhoun" To: X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] draft-ohara-capwap-lwapp-02.txt has been submitted Sender: capwap-admin@frascone.com Errors-To: capwap-admin@frascone.com X-BeenThere: capwap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: A list for CAPWAP technical discussions List-Unsubscribe: , List-Archive: Date: Thu, 31 Mar 2005 16:56:46 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C53655.ADDDB16D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, =20 The latest draft was sent into the IETF I-D editor today. Hopefully it = will be made available sometime soon for public viewing. =20 Thanks, =20 PatC ------_=_NextPart_001_01C53655.ADDDB16D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All,
=0A=
 
=0A=
The latest draft was sent into the IETF = I-D editor =0A= today. Hopefully it will be made available sometime soon for public =0A= viewing.
=0A=
 
=0A=
Thanks,
=0A=
 
=0A=
PatC
------_=_NextPart_001_01C53655.ADDDB16D-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap