From diameter-admin@frascone.com Tue Feb 1 05:12:53 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 FAA09796 for ; Tue, 1 Feb 2005 05:12:52 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8EA22057A for ; Tue, 1 Feb 2005 05:12:52 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 04B1D204E7 for ; Tue, 1 Feb 2005 05:11:31 -0500 (EST) Date: Tue, 01 Feb 2005 05:11:31 -0500 Message-ID: <20050201101131.11629.81345.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 Thu Feb 10 07:58: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 HAA25656 for ; Thu, 10 Feb 2005 07:58:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 61F1F20555; Thu, 10 Feb 2005 07:58:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E235D20588; Thu, 10 Feb 2005 07:58: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 5CBD820588 for ; Thu, 10 Feb 2005 07:57:04 -0500 (EST) Received: from hotmail.com (bay20-f23.bay20.hotmail.com [64.4.54.112]) by mail.frascone.com (Postfix) with ESMTP id 91FF720555 for ; Thu, 10 Feb 2005 07:57:01 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 10 Feb 2005 04:57:00 -0800 Message-ID: Received: from 202.156.2.218 by by20fd.bay20.hotmail.msn.com with HTTP; Thu, 10 Feb 2005 12:56:28 GMT X-Originating-IP: [202.156.2.218] X-Originating-Email: [saravanang@hotmail.com] X-Sender: saravanang@hotmail.com Reply-To: sgovindan@psl.com.sg From: "Saravanan Govindan" To: capwap@frascone.com Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 10 Feb 2005 12:57:00.0703 (UTC) FILETIME=[02C33AF0:01C50F70] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Objectives - Update to structure 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 Feb 2005 20:56:28 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) [Resend. Apologies for multiple posts.] Dear All, The Chairs have advised that the overall structure of the Objectives draft needs to be similar to RFC 3216. So the v00 draft has been changed to reflect this structure. You can find a v00-i (intermediate) draft with the changed structure at http://www.psl.com.sg/internet-drafts/draft-ietf-capwap-objectives-00-i.txt The content of the draft remains unchanged from v00. Please review the draft and send your feedback to the list. It would be great to get input on the Issues and Additions posted earlier. Cheers, Saravanan _________________________________________________________________ Get MSN Hotmail alerts on your mobile. http://mobile.msn.com/ac.aspx?cid=uuhp_hotmail _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Tue Feb 15 18:58: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 SAA00399 for ; Tue, 15 Feb 2005 18:58:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AB4722024F; Tue, 15 Feb 2005 18:58:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C771520254; Tue, 15 Feb 2005 18:58: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 3DC8920254 for ; Tue, 15 Feb 2005 18:57:16 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by mail.frascone.com (Postfix) with ESMTP id 1D04E2024F for ; Tue, 15 Feb 2005 18:57:13 -0500 (EST) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FNvBr04891; Wed, 16 Feb 2005 01:57:11 +0200 (EET) X-Scanned: Wed, 16 Feb 2005 01:56:42 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j1FNug24010268; Wed, 16 Feb 2005 01:56:42 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00RIBj6b; Wed, 16 Feb 2005 01:56:40 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FNudM07403; Wed, 16 Feb 2005 01:56:39 +0200 (EET) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Feb 2005 17:56:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: Comments on CAPWAP Objectives draft Thread-Index: AcUTuexxiZ6DwMKMTxe1cnLc19InmA== From: To: Cc: , X-OriginalArrivalTime: 15 Feb 2005 23:56:12.0869 (UTC) FILETIME=[EDC18F50:01C513B9] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Comments on CAPWAP 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: Tue, 15 Feb 2005 15:56:12 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Here are some comments the chairs have on the Objectives draft. We also = provided priority classifications for each objective as described in the = charter. I hope this generates some discussion and more comments. =20 Keep in mind that we are looking for a minimal set of requirements = needed for an interoperable protocol. =20 Regards, Dorothy 1. (general) Customer Requirements section should not be a sub-section = of each Objective, but rather a separate section for Service Providers = to list their requirements. As the draft's author list includes = Operators, this section should list Operator Specific requirements that = may be missed by equipment vendors. =20 2. (general) Some of the Objective Section include subsection. These = 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 3. (general) We need to clearly state the Requirement in each = objective. I don't believe the title of the objective is enough. The = way its stated now we have to surmise the requirement from the = description. =20 4. (general) Section 5.3 needs to be moved into the intro section. Objective: 5.2.3.i: Logical Groups, Priority: Mandatory Objective 5.2.3.ii: Should this be Mutual Exclusion of Control and = Data? Priority: Mandatory Objective 5.2.3.iii: Multiple Authentication Mechanisms: Desirable. =20 - 802.11i should be requirement, not an option. =20 Objective 5.2.4.i: Enable support for future wireless technologies: = Desirable - 802.11 first, 802.16 requirements in phase 1 time permitting. As = 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 = here? This is unclear. Transparency should be Mandatory Objective 5.2.5.i: Configuration Consistency: Priority: Mandatory=20 - Is the requirement to update configuration info to AC? Do you mean = to get into Provisioning here? =20 - firmware distribution needs to be its own requirement. Should this = be on control or data plane?=20 Objective 5.2.5.ii: System Wide resource state: Priority Mandatory - Define what statistics are needed. =09 Objective 5.2.6: Resource Control Objectives: Priority: Mandatory - Requirement is to maintain the 802.11e mapping. Can this be = expanded to include other 802.11 TG semantics? Objective 5.2.7 Traffic Separation: =20 Isn't this a duplicate of 5.2.3.ii? Objective 5.2.8: STA Admission Control Objectives =09 - Need to be better defined. Don't know what you are getting at = here. Objective 5.2.9: Centralized WTP Management: - Isn't this a duplicate of 5.2.5.i? Objective 5.2.10: CAPWAP Protocol Security: Priority: Mandatory =20 - Is this mutual authentication, should be clarified Objectives 5.2.11: System Wide Security : Priority: Mandatory Objectives 5.2.12: Centralized WTP management: Priority: Rejected - It sounds like you are requesting the AC not participate in = management. This doesn't seem relevant to establishing a control and = provisioning protocol for APs. At the very least it doesn't seem like a = high priority requirement for a phase 1 CAPWAP protocol. =20 Objectives: 5.2.13: Security Borderline Control: Priority: Desirable = - Is this necessary for a phase 1 CAPWAP protocol? Objective 5.2.14: Trust Model Definitions - Is this a duplicate of mutual authentication in 5.2.10? =20 Objectives 5.2.15: IEEE 802.11i Considerations -What is the proposal for key distribution in each case? Priority = Mandatory (for key distribution only) -What other considerations? _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 16 21:08: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 VAA25489 for ; Wed, 16 Feb 2005 21:08:04 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B703420593; Wed, 16 Feb 2005 21:08:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3662B20594; Wed, 16 Feb 2005 21:08: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 616F320594 for ; Wed, 16 Feb 2005 21:07:26 -0500 (EST) Received: from huawei.com (usaga01-in.huawei.com [63.250.163.245]) by mail.frascone.com (Postfix) with ESMTP id 9D55420593 for ; Wed, 16 Feb 2005 21:07:24 -0500 (EST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IC100L3L9QHCN@usaga01-in.huawei.com> for capwap@frascone.com; Wed, 16 Feb 2005 18:03:53 -0800 (PST) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IC100IC59QFGA@usaga01-in.huawei.com> for capwap@frascone.com; Wed, 16 Feb 2005 18:03:53 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [210.21.209.233]) by szxmc02-in.huawei.com (mshttpd); Thu, 17 Feb 2005 10:07:42 +0800 From: Yao Zhonghui 4776 To: capwap@frascone.com Cc: mmani@avaya.com, Dorothy.Gellert@nokia.com, sgovindan@psl.com.sg Message-id: <5aa0425ad675.5ad6755aa042@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Comments on Objective 5.2.14: Trust Model Definitions// 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, 17 Feb 2005 10:07:42 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT Deer Chairman and all, Here are some comments on Objective 5.2.15: This is a security consideration when we change 802.1X authenticator role from traditional AP to a centralized controller. Centralized pre-RSN architecture is existent in many enterprises and service providers and need to update to support up-to-date IEEE 802.11i security supplement.It is required from STA view that keep the trust relationship as same as IEEE 802.11i. IEEE 802.11i fixed 802.1X authenticator role on AP that identified by BSSID. In centralized network , 802.1X authenticator role may be relocated on a centralized controller, so if we want to keep the trust relationship of IEEE 802.11i, the centralized controller must be act same as AP of IEEE 802.11i from STA view. Or we can see the centralized controller as a logical AP of IEEE 802.11i. The concept of logical AP means that BSSID value on air radio MAC frame may be decided by the centralized controller. Thanks, Zhonghui Yao _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Feb 17 21:44: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 VAA14198 for ; Thu, 17 Feb 2005 21:44:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B34E81FE1E; Thu, 17 Feb 2005 21:44:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 930DA202FC; Thu, 17 Feb 2005 21:44: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 DAD4C202FC for ; Thu, 17 Feb 2005 21:43:17 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id A81FB1FE1E for ; Thu, 17 Feb 2005 21:43:13 -0500 (EST) Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1I2d67O006173; Fri, 18 Feb 2005 10:39:16 +0800 (SGT) From: "Cheng Hong" To: , Cc: , "'Saravanan Govindan'" , , "'Takashi Aramaki'" , "'Takako Sanda'" , Subject: RE: [Capwap] Comments on CAPWAP Objectives draft Organization: Panasonic Singapore Laboratories Message-ID: <020301c51563$7e244920$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 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: Fri, 18 Feb 2005 10:42:20 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Dorothy, Thanks a lot for your detailed comments on the draft. I think those are = very helpful in improving the draft. As the editor is on his business trip, and has some difficulty in = accessing the e-mail, his reply on those comments may come later. Here below, please find some of my personal comments to some of the = points inline. cheers Cheng Hong > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of=20 > Dorothy.Gellert@nokia.com > Sent: Wednesday, February 16, 2005 7:56 AM > To: capwap@frascone.com > Cc: mmani@avaya.com; Dorothy.Gellert@nokia.com > Subject: [Capwap] Comments on CAPWAP Objectives draft >=20 >=20 >=20 > Here are some comments the chairs have on the Objectives=20 > draft. We also provided priority classifications for each=20 > objective as described in the charter. I hope this generates=20 > some discussion and more comments. =20 >=20 > Keep in mind that we are looking for a minimal set of=20 > requirements needed for an interoperable protocol. =20 >=20 > Regards, > Dorothy >=20 >=20 > 1. (general) Customer Requirements section should not be a=20 > sub-section of each Objective, but rather a separate section=20 > for Service Providers to list their requirements. As the=20 > draft's author list includes Operators, this section should=20 > list Operator Specific requirements that may be missed by=20 > equipment vendors. =20 >=20 > 2. (general) Some of the Objective Section include=20 > subsection. These should be pulled out so we can prioritize=20 > 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=20 > each objective. I don't believe the title of the objective=20 > is enough. The way its stated now we have to surmise the=20 > requirement from the description. =20 >=20 > 4. (general) Section 5.3 needs to be moved into the intro section. >=20 > Objective: 5.2.3.i: Logical Groups, Priority: Mandatory=20 [Cheng] Agree [/Cheng] > Objective 5.2.3.ii: Should this be Mutual Exclusion of=20 > Control and Data? Priority: Mandatory=20 [Cheng] That is good suggestion. The titile would be changed. [/Cheng] >Objective 5.2.3.iii: =20 > Multiple Authentication Mechanisms: Desirable. =20 > - 802.11i should be requirement, not an=20 > option. =20 [Cheng] Agree. Given the 802.11i is a already part of 11, it has to be = supported. The intention is to require the CAPWAP to support other commonly used authentication mechanism in current hotspot, without compromising the support of 11i. This could be clarified with extra text. [/Cheng] > Objective 5.2.4.i: Enable support for future wireless=20 > technologies: Desirable > - 802.11 first, 802.16 requirements in=20 > phase 1 time permitting. As stated in Charter.=20 [Cheng] Agree.=20 [/Cheng] >Objective=20 > 5.2.4.ii: Enable support for new IEEE requirements:=20 > Desirable Objective=20 >5.2.4.iii Access Requirements: Do you=20 > mean transparency here? This is unclear. Transparency=20 > should be Mandatory [Cheng] It means that the CAPWAP protocol should not affect the end terminal, especially over the air interface. However, it should not precluded that the end terminal could have some enhanced functions implemented to make use of the new features provided = by CAPWAP. In this sense, the requirement also means legacy end terminal support. [/Cheng] > Objective 5.2.5.i: Configuration Consistency: Priority: Mandatory=20 > - Is the requirement to update=20 > configuration info to AC? Do you mean to get into=20 > Provisioning here? =20 [Cheng] It could be considred as the provisioning. I guess this was also part of = the problem statement of the CAPWAP.=20 [/Cheng] > - firmware distribution needs to be its=20 > own requirement. Should this be on control or data plane?=20 [Cheng] It has to be in the control plane, since it affects the operation of the WTP. Also relates to the Objective 5.2.9 below. (some comments there) [/Cheng] > Objective 5.2.5.ii: System Wide resource state: Priority Mandatory > - Define what statistics are needed. [Cheng] Not sure if the Objective draft is a good place to list out all the statistics. It could be part of the protocol job. Another alternative is = for the MIB definiton at the later stage. [/Cheng] > =09 > Objective 5.2.6: Resource Control Objectives: Priority: Mandatory > - Requirement is to maintain the=20 > 802.11e mapping. Can this be expanded to include other=20 > 802.11 TG semantics? [Cheng] So far, 11 only has 11e as the QoS control mechansim. We are also aware = tha there are other TGs that may affect the resource control, e.g. TGk, TGu, = and TGv. But, those drafts are not yet become stable (u & v just started). I think this other aspects has to be covered in objective 5.2.4 [/Cheng] >=20 > Objective 5.2.7 Traffic Separation: =20 > Isn't this a duplicate of 5.2.3.ii? [Cheng] In deed they overlap a bit here. I guess the 5.2.3.ii could be merged = into this section. [/Cheng] > Objective 5.2.8: STA Admission Control Objectives =09 > - Need to be better defined. Don't=20 > know what you are getting at here. [Cheng] This objective is on how the CAPWAP can support the admission control functions. To make use of the CAPWAP arch, it is expected that the ACU = would most likely be implemented at the AC. In that case, the CAPWAP would = need to provide the support of those SME-MLME SAP functions defined by the 11. = (11e has some informative text regarding the admission control unit implementation). [/Cheng] > Objective 5.2.9: Centralized WTP Management: > - Isn't this a duplicate of 5.2.5.i? [Cheng] Yes. That part of the 5.2.5.i should be merged into this section. The section 5.2.5 should concentrate on the montioring aspect, e.g. ways for centralized controller to be aware of the status/version of the WTP. And this section on the management aspect, i.e. the provisioning part. [/Cheng] =20 > Objective 5.2.10: CAPWAP Protocol Security: Priority: Mandatory =20 > - Is this mutual authentication, should=20 > be clarified [Cheng] It requires mutual authentication of the WTP and AC, AND data confidentiality, integrity, and authentication of the communication = between them. [/Cheng] > 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=20 > AC not participate in management. This doesn't seem relevant=20 > to establishing a control and provisioning protocol for APs.=20 > At the very least it doesn't seem like a high priority=20 > requirement for a phase 1 CAPWAP protocol. =20 >=20 > Objectives: 5.2.13: Security Borderline Control: Priority:=20 > Desirable=20 > - Is this necessary for a phase 1=20 > CAPWAP protocol? >=20 > Objective 5.2.14: Trust Model Definitions > - Is this a duplicate of mutual=20 > authentication in 5.2.10? =20 >=20 > Objectives 5.2.15: IEEE 802.11i Considerations > -What is the proposal for key=20 > distribution in each case? Priority Mandatory (for key=20 > distribution only) [Cheng] This depends on the protocol proposals. If the proposal adapts the arch = that the keys are derived at the AC, it needs to provide a secure and = reliable way to distribute and synchronize the keys with the AC and WTP, and at = the same time keeps the over the air protocol unaffected. [/Cheng] > -What other considerations? >=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 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Feb 17 21:44:25 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 VAA14236 for ; Thu, 17 Feb 2005 21:44:21 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 006EE20541; Thu, 17 Feb 2005 21:44:19 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D0D5202FC; Thu, 17 Feb 2005 21:44:07 -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 AAC79202FC for ; Thu, 17 Feb 2005 21:43:31 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 8F93E1FE1E for ; Thu, 17 Feb 2005 21:43:29 -0500 (EST) Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1I2dTdX006192; Fri, 18 Feb 2005 10:39:37 +0800 (SGT) From: "Cheng Hong" To: , Cc: , "'Saravanan Govindan'" , , "'Takashi Aramaki'" , "'Takako Sanda'" , Subject: RE: [Capwap] Comments on CAPWAP Objectives draft Organization: Panasonic Singapore Laboratories Message-ID: <020401c51563$8b291c40$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 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: Fri, 18 Feb 2005 10:42:42 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Dorothy, Thanks a lot for your detailed comments on the draft. I think those are = very helpful in improving the draft. As the editor is on his business trip, and has some difficulty in = accessing the e-mail, his reply on those comments may come later. Here below, please find some of my personal comments to some of the = points inline. cheers Cheng Hong > -----Original Message----- > From: capwap-admin@frascone.com=20 > [mailto:capwap-admin@frascone.com] On Behalf Of=20 > Dorothy.Gellert@nokia.com > Sent: Wednesday, February 16, 2005 7:56 AM > To: capwap@frascone.com > Cc: mmani@avaya.com; Dorothy.Gellert@nokia.com > Subject: [Capwap] Comments on CAPWAP Objectives draft >=20 >=20 >=20 > Here are some comments the chairs have on the Objectives=20 > draft. We also provided priority classifications for each=20 > objective as described in the charter. I hope this generates=20 > some discussion and more comments. =20 >=20 > Keep in mind that we are looking for a minimal set of=20 > requirements needed for an interoperable protocol. =20 >=20 > Regards, > Dorothy >=20 >=20 > 1. (general) Customer Requirements section should not be a=20 > sub-section of each Objective, but rather a separate section=20 > for Service Providers to list their requirements. As the=20 > draft's author list includes Operators, this section should=20 > list Operator Specific requirements that may be missed by=20 > equipment vendors. =20 >=20 > 2. (general) Some of the Objective Section include=20 > subsection. These should be pulled out so we can prioritize=20 > 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=20 > each objective. I don't believe the title of the objective=20 > is enough. The way its stated now we have to surmise the=20 > requirement from the description. =20 >=20 > 4. (general) Section 5.3 needs to be moved into the intro section. >=20 > Objective: 5.2.3.i: Logical Groups, Priority: Mandatory=20 [Cheng] Agree [/Cheng] > Objective 5.2.3.ii: Should this be Mutual Exclusion of=20 > Control and Data? Priority: Mandatory=20 [Cheng] That is good suggestion. The titile would be changed. [/Cheng] >Objective 5.2.3.iii: =20 > Multiple Authentication Mechanisms: Desirable. =20 > - 802.11i should be requirement, not an=20 > option. =20 [Cheng] Agree. Given the 802.11i is a already part of 11, it has to be = supported. The intention is to require the CAPWAP to support other commonly used authentication mechanism in current hotspot, without compromising the support of 11i. This could be clarified with extra text. [/Cheng] > Objective 5.2.4.i: Enable support for future wireless=20 > technologies: Desirable > - 802.11 first, 802.16 requirements in=20 > phase 1 time permitting. As stated in Charter.=20 [Cheng] Agree.=20 [/Cheng] >Objective=20 > 5.2.4.ii: Enable support for new IEEE requirements:=20 > Desirable Objective=20 >5.2.4.iii Access Requirements: Do you=20 > mean transparency here? This is unclear. Transparency=20 > should be Mandatory [Cheng] It means that the CAPWAP protocol should not affect the end terminal, especially over the air interface. However, it should not precluded that the end terminal could have some enhanced functions implemented to make use of the new features provided = by CAPWAP. In this sense, the requirement also means legacy end terminal support. [/Cheng] > Objective 5.2.5.i: Configuration Consistency: Priority: Mandatory=20 > - Is the requirement to update=20 > configuration info to AC? Do you mean to get into=20 > Provisioning here? =20 [Cheng] It could be considred as the provisioning. I guess this was also part of = the problem statement of the CAPWAP.=20 [/Cheng] > - firmware distribution needs to be its=20 > own requirement. Should this be on control or data plane?=20 [Cheng] It has to be in the control plane, since it affects the operation of the WTP. Also relates to the Objective 5.2.9 below. (some comments there) [/Cheng] > Objective 5.2.5.ii: System Wide resource state: Priority Mandatory > - Define what statistics are needed. [Cheng] Not sure if the Objective draft is a good place to list out all the statistics. It could be part of the protocol job. Another alternative is = for the MIB definiton at the later stage. [/Cheng] > =09 > Objective 5.2.6: Resource Control Objectives: Priority: Mandatory > - Requirement is to maintain the=20 > 802.11e mapping. Can this be expanded to include other=20 > 802.11 TG semantics? [Cheng] So far, 11 only has 11e as the QoS control mechansim. We are also aware = tha there are other TGs that may affect the resource control, e.g. TGk, TGu, = and TGv. But, those drafts are not yet become stable (u & v just started). I think this other aspects has to be covered in objective 5.2.4 [/Cheng] >=20 > Objective 5.2.7 Traffic Separation: =20 > Isn't this a duplicate of 5.2.3.ii? [Cheng] In deed they overlap a bit here. I guess the 5.2.3.ii could be merged = into this section. [/Cheng] > Objective 5.2.8: STA Admission Control Objectives =09 > - Need to be better defined. Don't=20 > know what you are getting at here. [Cheng] This objective is on how the CAPWAP can support the admission control functions. To make use of the CAPWAP arch, it is expected that the ACU = would most likely be implemented at the AC. In that case, the CAPWAP would = need to provide the support of those SME-MLME SAP functions defined by the 11. = (11e has some informative text regarding the admission control unit implementation). [/Cheng] > Objective 5.2.9: Centralized WTP Management: > - Isn't this a duplicate of 5.2.5.i? [Cheng] Yes. That part of the 5.2.5.i should be merged into this section. The section 5.2.5 should concentrate on the montioring aspect, e.g. ways for centralized controller to be aware of the status/version of the WTP. And this section on the management aspect, i.e. the provisioning part. [/Cheng] =20 > Objective 5.2.10: CAPWAP Protocol Security: Priority: Mandatory =20 > - Is this mutual authentication, should=20 > be clarified [Cheng] It requires mutual authentication of the WTP and AC, AND data confidentiality, integrity, and authentication of the communication = between them. [/Cheng] > 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=20 > AC not participate in management. This doesn't seem relevant=20 > to establishing a control and provisioning protocol for APs.=20 > At the very least it doesn't seem like a high priority=20 > requirement for a phase 1 CAPWAP protocol. =20 >=20 > Objectives: 5.2.13: Security Borderline Control: Priority:=20 > Desirable=20 > - Is this necessary for a phase 1=20 > CAPWAP protocol? >=20 > Objective 5.2.14: Trust Model Definitions > - Is this a duplicate of mutual=20 > authentication in 5.2.10? =20 >=20 > Objectives 5.2.15: IEEE 802.11i Considerations > -What is the proposal for key=20 > distribution in each case? Priority Mandatory (for key=20 > distribution only) [Cheng] This depends on the protocol proposals. If the proposal adapts the arch = that the keys are derived at the AC, it needs to provide a secure and = reliable way to distribute and synchronize the keys with the AC and WTP, and at = the same time keeps the over the air protocol unaffected. [/Cheng] > -What other considerations? >=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 >=20 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 04:31:17 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 EAA21000 for ; Wed, 23 Feb 2005 04:31:16 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C8FFC205C6; Wed, 23 Feb 2005 04:31:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 74336205C1; Wed, 23 Feb 2005 04: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 9570E205C1 for ; Wed, 23 Feb 2005 04:30:27 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id C9E39205B3 for ; Wed, 23 Feb 2005 04:30:23 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1N9QfHJ008903; Wed, 23 Feb 2005 17:26:41 +0800 (SGT) Message-Id: <200502230926.j1N9QfHJ008903@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: , Cc: Subject: RE: [Capwap] Comments on CAPWAP Objectives draft 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 In-Reply-To: Thread-Index: AcUTuexxiZ6DwMKMTxe1cnLc19InmAFy31pA 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, 23 Feb 2005 17:29:48 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Dorothy, Mani Thank you for your comments and the priority classifications. The co-authors and I have followed your suggestion to separate certain subsections into full objectives. These are being posted as separate threads for discussion. Also, for reviewing convenience alone, we have included the changes you have suggested in to another intermediate draft. This link for this is; http://www.psl.com.sg/internet-drafts/draft-ietf-capwap-objectives-v00-i1.tx t Additionally, please see inline for responses. > 1. (general) Customer Requirements section should not be a > sub-section of each Objective, but rather a separate section > for Service Providers to list their requirements. As the > draft's author list includes Operators, this section should > list Operator Specific requirements that may be missed by > equipment vendors. > I see. So, a new section will be included to highlight Operator requirements. In addition to the operators in the author list, I would like to request other operators to put forward requirements that they feel are important for CAPWAP. > 2. (general) Some of the Objective Section include > subsection. These 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 > Ok. Please see the new Additions (Additions #9 - #20). These represent the subsections that have been made into separate objectives. They are also included in the intermediate draft mentioned above. > 3. (general) We need to clearly state the Requirement in > each objective. I don't believe the title of the objective > is enough. The way its stated now we have to surmise the > requirement from the description. > Ok. Please see the new Additions (Additions #9 - #20). They include a specific requirement for each objective. > 4. (general) Section 5.3 needs to be moved into the intro section. > > Objective: 5.2.3.i: Logical Groups, Priority: Mandatory Objective See Additions #9 - 'Logical Groups' > Objective 5.2.3.ii: Should this be Mutual Exclusion of > Control and Data? Priority: Mandatory Objective This objective is about mutual exclusion of control and data. Changes have been made to the "Traffic Separation" objective (5.2.7) See Additions #10 - 'Support for Traffic Separation' > Objective 5.2.3.iii: Multiple Authentication Mechanisms: Desirable. > - 802.11i should be requirement, not an option. > See Additions #11 - 'Multiple Authentication Mechanisms' > Objective 5.2.4.i: Enable support for future wireless > technologies: Desirable > - 802.11 first, 802.16 requirements in > phase 1 time permitting. As stated in Charter. Ok. 802.11 will be first. See Additions #12 - 'Future Wireless Technologies' > Objective 5.2.4.ii: Enable support for new IEEE > requirements: Desirable Objective See Additions #13 - 'New IEEE Requirements' > Objective 5.2.4.iii Access > Requirements: Do you mean transparency here? This is > unclear. Transparency should be Mandatory > Yes. This objective refers to transparency; End-users should not be affected by CAPWAP. See Additions #14 - 'End-user Transparency' > Objective 5.2.5.i: Configuration Consistency: Priority: Mandatory > - Is the requirement to update > configuration info to AC? Do you mean to get into > Provisioning here? Yes. The CAPWAP protocol is to collect configuration information and make this aware to the AC. Provisioning will be when the AC makes configuration decisions based on the information. See Additions #15 - 'Configuration Consistency' > - firmware distribution needs to be its > own requirement. Should this be on control or data plane? Firmware distribution should be on the control plane. See Additions #16 - 'Firmware Distribution' > Objective 5.2.5.ii: System Wide resource state: Priority Mandatory > - Define what statistics are needed. > Maybe the objectives can give examples of statistics since the specifics would depend on the protocol. See Additions #17 - 'Statistics' > Objective 5.2.6: Resource Control Objectives: Priority: Mandatory > - Requirement is to maintain the > 802.11e mapping. Can this be expanded to include other > 802.11 TG semantics? > This objective can be expanded to include other 802.11 TG semantics that are related to resource control. We will need to point out that some of the TGs are under progress, so they need to be dealt with appropriately. See Additions #18 - 'Resource Control' > Objective 5.2.7 Traffic Separation: > Isn't this a duplicate of 5.2.3.ii? > It is similar 5.2.3ii. See Additions #10 - 'Support for Traffic Separation' in which 5.2.3ii has been combined with 5.2.7 > Objective 5.2.8: STA Admission Control Objectives > - Need to be better defined. Don't > know what you are getting at here. > This was one of the original objectives from the individual drafts. The authors later realized that this needed to be described in a more clear manner. Additions #4 - 'STA Admission Contro', which was posted to the mailing list earlier, explains this objective better. Please consider Additions #4 - 'STA Admission Control' as a proposed change. > Objective 5.2.9: Centralized WTP Management: > - Isn't this a duplicate of 5.2.5.i? > This is similar to 5.2.5i. It can be removed now that 5.2.5i has been made a separate objective. > Objective 5.2.10: CAPWAP Protocol Security: Priority: Mandatory > - Is this mutual authentication, should > be clarified > This objective includes both mutual authentication and the subsequent secure exchanges between AC and WTPs. So it is meant to cover the complete protocol security between AC and WTPs. This has bee clarified in Addition #19 - 'CAPWAP Protocol Security'. > Objectives 5.2.11: System Wide Security : Priority: Mandatory > OK > Objectives 5.2.12: Centralized WTP management: Priority: Rejected > - It sounds like you are requesting the > AC not participate in management. This doesn't seem relevant > to establishing a control and provisioning protocol for APs. > At the very least it doesn't seem like a high priority > requirement for a phase 1 CAPWAP protocol. > OK > Objectives: 5.2.13: Security Borderline Control: Priority: > Desirable > - Is this necessary for a phase 1 > CAPWAP protocol? > This objective relates to the logical groups (5.2.3i). We will need to get more information on the details of this objective. > Objective 5.2.14: Trust Model Definitions > - Is this a duplicate of mutual > authentication in 5.2.10? > This objective deals with IEEE 802.11i, so it does not relate directly to AC-WTP mutual authentication & security in 5.2.10. Additions #8 - 'Trust Model Definition', posted earlier to the mailing list, details proposed changes to this objective that the authors considered. Please see Additions #8 - 'Trust Model Definition'. > Objectives 5.2.15: IEEE 802.11i Considerations > -What is the proposal for key > distribution in each case? Priority Mandatory (for key > distribution only) > -What other considerations? > For key distribution, a proposal is to make CAPWAP aware of IEEE 802.11i exchanges and the locations of the authenticator and encryption points. This need not be explicit but rather could be an implicit distinction made during initial configuration of WTPs. This way, the CAPWAP protocol can be made to include operations for handling key exchanges in the different cases, i.e. authenticator, encryption at AC or at WTP. Cheers, Saravanan _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 04:43: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 EAA22801 for ; Wed, 23 Feb 2005 04:43:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DEF84205D2; Wed, 23 Feb 2005 04:43:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 730C9205C4; Wed, 23 Feb 2005 04:43: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 66C78205C4 for ; Wed, 23 Feb 2005 04:42:06 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id E4EBC205C2 for ; Wed, 23 Feb 2005 04:42:03 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1N9cid8009350 for ; Wed, 23 Feb 2005 17:38:44 +0800 (SGT) Message-Id: <200502230938.j1N9cid8009350@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: 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: AcUZi+YtW7iATNmURHS1bbwi4MFtFA== X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Additions #9 - Logical Groups 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, 23 Feb 2005 17:41:51 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Additions #9 - Logical Groups Issue: Replace subsections as full objectives so they can be reviewed independently Proposed change: Replace subsection-5.2.3.i with the following objective Classification: Architecture Priority: Mandatory Description: Large WLAN deployments are complex and expensive. Furthermore, enterprises are under pressure to improve the efficiency of their expenditures. Shared WLAN deployments, where a number of logical networks cover a single physical WLAN infrastructure, are increasingly popular because they allow deployment and management costs to be spread across businesses. Such networks are distinct from traditional WLANs in which each WTP represents one complete subset of a larger WLAN system. In shared deployments, each WTP represents a number of subsets of possibly a number of larger WLAN systems. So with such deployments, WLANs need to be managed in terms of logical groups instead of physical devices. Protocol Requirement: The CAPWAP protocol must be capable of controlling WTPs in terms of logical user groups. Motivation & Protocol Benefits: Commercial realities necessitate that WLANs be manageable in terms of its user groups. This allows separation of user services and underlying infrastructure management. A protocol that addresses this need greatly benefits network operators. Relation to Problem Statement: This objective addresses the problem of management complexity in terms of costs. Cost complexity is reduced by sharing WLAN deployments. Consequently, deployment and management cost-efficiencies are realized. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 04:51: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 EAA24119 for ; Wed, 23 Feb 2005 04:51:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4894A205E5; Wed, 23 Feb 2005 04:51:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF413205D5; Wed, 23 Feb 2005 04:51: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 68AE5205D5 for ; Wed, 23 Feb 2005 04:50:29 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 8CEF1205D0 for ; Wed, 23 Feb 2005 04:50:26 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1N9l7Wc009608 for ; Wed, 23 Feb 2005 17:47:07 +0800 (SGT) Message-Id: <200502230947.j1N9l7Wc009608@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: 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: AcUZi+YtW7iATNmURHS1bbwi4MFtFAAAAu+Q X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Additions #10 - Support for Traffic Separation 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, 23 Feb 2005 17:50:14 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Additions #10 - Support for Traffic Separation Issue: Include subsection 5.2.3ii-'Mutual separation of Control and Communications' in Objective-5.2.7-'Support for Traffic Separation'. Proposed changes are to be made to Objective-5.2.7 Proposed change: Classification: Operational Priority: Mandatory Description: (Insert after first paragraph) Furthermore, in the context of shared infrastructure, the mutual separation of data and control also addresses security concerns. (Insert after second paragraph) And in shared infrastructure WLANs, which may contain traffic belonging to different logical groups with possibly varying needs, it is important that each group's traffic be separated. Protocol Requirement: The CAPWAP protocol should separate transport of control and data information. Motivation and Protocol Benefits: (Insert after second paragraph) Separation of WTP control and data allows for secure realization of shared WLANs. Relation to Problem Statement: (Insert after first sentence) This objectives allows for simplified control as this can be separated from the task of data transport. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 04:56: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 EAA24814 for ; Wed, 23 Feb 2005 04:56:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D66E5205F4; Wed, 23 Feb 2005 04:56:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D5CE0205E2; Wed, 23 Feb 2005 04: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 F0F4D205E2 for ; Wed, 23 Feb 2005 04:55:30 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 4AEF2205DE for ; Wed, 23 Feb 2005 04:55:27 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1N9q79O009777 for ; Wed, 23 Feb 2005 17:52:07 +0800 (SGT) Message-Id: <200502230952.j1N9q79O009777@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: 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: AcUZi+YtW7iATNmURHS1bbwi4MFtFAAATAow X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Additions #11 - Multiple Authentication Mechanisms 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, 23 Feb 2005 17:55:13 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Additions #11 - Multiple Authentication Mechanisms Issue: Replace subsections as full objectives so they can be reviewed independently. Replace subsection-5.2.3iii-'Multiple Authentication Mechanisms' as a separate objective titled 'Multiple Authentication Mechanisms'. Proposed change: Classification: Architecture Priority: Desirable Description: Shared WLAN infrastructure raise the issue of multiple authentication mechanisms. This is because each logical group is likely to consist of users belonging to different service providers or to different WLAN domains. As a result, their authentication needs will be different. While CAPWAP is required to support IEEE 802.11i, it is also necessary for it to support other authentication mechanisms. For example, one logical group may use IEEE 802.11i while another may use web authentication. CAPWAP must be able to operate in such shared WLANs. Protocol Requirement: The CAPWAP protocol must support different authentication mechanisms in addition to IEEE 802.11i. Motivation and Protocol Benefits: The benefit of supporting various authentication mechanisms is that the protocol then becomes flexible for use in various deployments. The protocol therefore does not mandate the use of any particular mechanisms which may not be appropriate. Relation to Problem Statement: This objective relates to the problem of management complexity. Shared WLAN infrastructure simplifies management of large WLANs. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 04: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 EAA25199 for ; Wed, 23 Feb 2005 04:59:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0549C205DE; Wed, 23 Feb 2005 04:59:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1CFC7205F1; Wed, 23 Feb 2005 04: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 7A450205EA for ; Wed, 23 Feb 2005 04:58:11 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id D256C205DE for ; Wed, 23 Feb 2005 04:58:08 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1N9snp8009869 for ; Wed, 23 Feb 2005 17:54:49 +0800 (SGT) Message-Id: <200502230954.j1N9snp8009869@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: 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: AcUZi+YtW7iATNmURHS1bbwi4MFtFAAATAowAAAtkxA= X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Additions #12 - Future Wireless Technologies 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, 23 Feb 2005 17:57:56 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Additions #12 - Future Wireless Technologies Issue: Replace subsections as full objectives so they can be reviewed independently. Replace subsection-5.2.4i-'Enable Support for Future Wireless Technologies' as a separate objective titled 'Support for Future Wireless Technologies'. Proposed change: Classification: Architecture Priority: Desirable Description: The rapid pace of technology developments means that new advances need to be catered for in current analyses. Among these is the support for new wireless technologies within the CAPWAP protocol, such as IEEE 802.16. The protocol should therefore not rely on specifics of IEEE 802.11 technology. Protocol Requirement: The CAPWAP protocol must be applicable for IEEE 802.11 and other wireless technologies. Motivation and Protocol Benefits: There are many benefits to an extensible protocol. It allows for application in different networks and provides greater scope. Furthermore, service providers require WLAN solutions that will be able to meet current and future market requirements. Relation to Problem Statement: The Problem Statement describes some of the advances taking place in other standards bodies like the IEEE. It is important for the CAPWAP protocol to reflect the advances and provide a framework in which they can be supported. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 05:01: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 FAA25450 for ; Wed, 23 Feb 2005 05:01:04 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD9DF205FD; Wed, 23 Feb 2005 05:01:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5EC8F205CF; Wed, 23 Feb 2005 05:01: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 B64E7205CF for ; Wed, 23 Feb 2005 05:00:46 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 71876204FE for ; Wed, 23 Feb 2005 05:00:44 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1N9vLB0009981 for ; Wed, 23 Feb 2005 17:57:21 +0800 (SGT) Message-Id: <200502230957.j1N9vLB0009981@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: 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: AcUZi+YtW7iATNmURHS1bbwi4MFtFAAATAowAAAtkxAAAB1nEA== X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Additions #13 - New IEEE Requirements 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, 23 Feb 2005 18:00:28 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Additions #13 - New IEEE Requirements Issue: Replace subsections as full objectives so they can be reviewed independently. Replace subsection-5.2.4ii-'Enable Support for New IEEE Requirements' as a separate objective titled 'Support for New IEEE Requirements'. Proposed change: Classification: Architecture Priority: Desirable Description: The IEEE is currently reviewing IEEE 802.11 functionality. It is expected that the review will result in new functional blocks, interfaces or information flows. The CAPWAP protocol must be able to incorporate these revisions with minimal change. Protocol Requirement: The CAPWAP protocol must be openly structured to support new IEEE extensions. Motivation and Protocol Benefits: There are a number of advances being made within the IEEE regarding the functionality of IEEE 802.11 technology. Since this represents one of the major wireless technologies in use today, it will be beneficial for CAPWAP to incorporate the relevant new extensions. Relation to Problem Statement: The Problem Statement presents an overview of the task of the IEEE 802.11 working group. This group is focussed on defining the functional architecture of WTPs. It is necessary for the CAPWAP protocol to reflect these definitions. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 05:09: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 FAA26902 for ; Wed, 23 Feb 2005 05:09:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 06D4720604; Wed, 23 Feb 2005 05:09:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5D65A205EF; Wed, 23 Feb 2005 05:09: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 8C07A205EF for ; Wed, 23 Feb 2005 05:08:20 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id E8859205CF for ; Wed, 23 Feb 2005 05:08:17 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1NA4w1N010187 for ; Wed, 23 Feb 2005 18:04:58 +0800 (SGT) Message-Id: <200502231004.j1NA4w1N010187@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: 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: AcUZi+YtW7iATNmURHS1bbwi4MFtFAAATAowAAAtkxAAAB1nEAAAP90Q X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Additions #14 - End-user Transparency 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, 23 Feb 2005 18:08:05 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Additions #14 - End-user Transparency Issue: Replace subsections as full objectives so they can be reviewed independently. Replace subsection-5.2.4iii-'User(Client) Access Requirement' as a separate objective titled 'End-user Transparency'. Proposed change: Classification: Architecture Priority: Mandatory Description: The CAPWAP protocol will be used between a centralized controller and a number of WTPs. Its operations should be independent of the wireless end-user. The end-users should not be required to be aware of the existence of the CAPWAP protocol. Protocol Requirement: End-users should not be required to recognize the CAPWAP protocol. Motivation and Protocol Benefits: IEEE 802.11 based end-user devices are mature and wide-spread. It would be beneficial for CAPWAP not to impose new requirements on these numerous devices. Relation to Problem Statement: The Problem Statement highlights the challenges faced by large WLANs consisting of many WTPs. Since it does not refer to end-user operations, this objective is necessary to emphasize this independence. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 05:11: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 FAA27205 for ; Wed, 23 Feb 2005 05:11:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 511C920609; Wed, 23 Feb 2005 05:11:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 33EF0205FC; Wed, 23 Feb 2005 05:11: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 762A6205FC for ; Wed, 23 Feb 2005 05:10:38 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 42F06205F9 for ; Wed, 23 Feb 2005 05:10:35 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1NA7EBs010261 for ; Wed, 23 Feb 2005 18:07:14 +0800 (SGT) Message-Id: <200502231007.j1NA7EBs010261@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: 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: AcUZi+YtW7iATNmURHS1bbwi4MFtFAAATAowAAAtkxAAAB1nEAAAP90QAAAVVPA= X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Additions #15 - Configuration Consistency 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, 23 Feb 2005 18:10:21 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Additions #15 - Configuration Consistency Issue: Replace subsections as full objectives so they can be reviewed independently. Replace subsection-5.2.5i-'Configuration Consistency' as a separate objective titled 'Configuration Consistency'. Proposed change: Classification: Operational Priority: Mandatory Description: The scale of WLANs in the CAPWAP context results in numerous WTPs. Each of these WTPs need to be configured and managed in a consistent manner. This is possible by providing the centralized controller with regular updates on the state of their operations. The centralized controller in turn can consistently control the devices based on the information available. Protocol Requirement: The CAPWAP protocol must be capable of allowing regular exchanges of statistics and other state information. Motivation and Protocol Benefits: A protocol that has access to regular state information can result in enhanced WLAN performance. It provides more information on which to based management decisions. Relation to Problem Statement: One of the major challenges described in the Problem Statement is that of maintaining consistent configuration across the numerous WTPs of a WLAN. This objective fundamentally addresses this challenge by providing relevant statistics and other information based on which configuration can be appropriately maintained. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 05:13: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 FAA27556 for ; Wed, 23 Feb 2005 05:13:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 39EF420612; Wed, 23 Feb 2005 05:13:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BD9AF20605; Wed, 23 Feb 2005 05:13: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 49E1420605 for ; Wed, 23 Feb 2005 05:12:39 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id C971E20600 for ; Wed, 23 Feb 2005 05:12:36 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1NA9HTA010332 for ; Wed, 23 Feb 2005 18:09:17 +0800 (SGT) Message-Id: <200502231009.j1NA9HTA010332@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: 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: AcUZi+YtW7iATNmURHS1bbwi4MFtFAAATAowAAAtkxAAAB1nEAAAP90QAAAVVPAAABWwIA== X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Additions #16 - Firmware Distribution 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, 23 Feb 2005 18:12:24 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Additions #16 - Firmware Distribution Issue: Replace subsections as full objectives so they can be reviewed independently. Replace parts of subsection-5.2.5i-'Configuration Consistency' as a separate objective titled 'Firmware Distribution'. Proposed change: Classification: Operational Priority: Mandatory Description: One specific aspect of configuration consistency is the firmware used by various WTPs. The scale of large WLANs introduces possibilities for variations in the firmware used among WTPs. This objective highlights the need for the CAPWAP protocol to deliver the appropriate versions of firmware to WTPs. Protocol Requirement: The CAPWAP protocol must support delivery of firmware updates. Motivation and Protocol Benefits: The CAPWAP protocol interfaces many WTPs to a centralized controller. Firmware distribution allows these interfaces to appropriately equivalent thereby allowing for reduced complexity. Relation to Problem Statement: Inconsistencies in the configuration of WTPs has been identified as a major challenge for large-scale WTPs. This objectives helps overcome the challenge by providing for a way of WTPs to operate under equivalent versions of firmware. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 05:15: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 FAA27912 for ; Wed, 23 Feb 2005 05:15:04 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D2C9F2061F; Wed, 23 Feb 2005 05:15:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 59C2720611; Wed, 23 Feb 2005 05:15: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 CF19520607 for ; Wed, 23 Feb 2005 05:14:54 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 9902420600 for ; Wed, 23 Feb 2005 05:14:52 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1NABXSo010421 for ; Wed, 23 Feb 2005 18:11:33 +0800 (SGT) Message-Id: <200502231011.j1NABXSo010421@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: 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: AcUZi+YtW7iATNmURHS1bbwi4MFtFAAATAowAAAtkxAAAB1nEAAAP90QAAAVVPAAABWwIAAAEPxQ X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Additions #17 - Statistics 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, 23 Feb 2005 18:14:40 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Additions #17 - Statistics Issue: Replace subsections as full objectives so they can be reviewed independently. Replace subsection-5.2.5ii-'System-wide Resource State' as a separate objective titled 'System-wide Resource State'. Proposed change: Classification: Operational Priority: Mandatory Description: The centralized WLAN architecture is made up of a switching segment and wireless medium segment. In the switching segment, network congestion, WTP status and firmware information have to be monitored. In the wireless medium segment, the dynamic nature of the medium itself has to be monitored. Overall, there are also various statistics that are required for operation. The CAPWAP protocol should be capable of monitoring various information sources. Moreover, given the relationship among information sources, CAPWAP should combine information from them. For example, statistics information may be merged with status signals. Some of the statistics information include; congestion state, interference levels, WTP load, loss rates and various delay factors. Protocol Requirement: The CAPWAP protocol must allow for the exchange of statistics, congestion and other WLAN state information. Motivation and Protocol Benefits: The effectivness of a protocol is based on the relevance of informaiton on which it operates. This objectve for system-wide resource monitoring can provide the appropriate information to the CAPWAP protocol. Relation to Problem Statement: The Problem Statement highlights the problem of dealing with a large number of WTPs and the dynamic nature of the wireless medium. Information on the state of WTPs and the medium is important to deal with them effectively. So this objective relates to the problem of managing consistency in large WLANs. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 05:19: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 FAA28390 for ; Wed, 23 Feb 2005 05:19:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1BE0B20621; Wed, 23 Feb 2005 05:19:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ABEFB20607; Wed, 23 Feb 2005 05:19: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 21FA320607 for ; Wed, 23 Feb 2005 05:18:28 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 9A33120600 for ; Wed, 23 Feb 2005 05:18:25 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1NAF63R010541 for ; Wed, 23 Feb 2005 18:15:06 +0800 (SGT) Message-Id: <200502231015.j1NAF63R010541@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: 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: AcUZi+YtW7iATNmURHS1bbwi4MFtFAAATAowAAAtkxAAAB1nEAAAP90QAAAVVPAAABWwIAAAEPxQAAAVjZA= X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Additions #18 - Resource Control 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, 23 Feb 2005 18:18:13 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Additions #18 - Resource Control Issue: Additional text clarifying use of 802.11e and other 802.11 TG semantics for QoS mapping. Proposed changes are for objective5.2.6-'Resource Control Objective' Proposed change: Priority: Mandatory Description: (Insert after the second paragraph) In addition to IEEE 802.11e, there are a number of other IEEE Task Groups that may affect network resources. These include IEEE TGk, TGu and TGv, which are currenlty under progress. CAPWAP should therefore not be restricted to IEEE 802.11e based mapping. Protocol Requirement: The CAPWAP protocol must maintain IEEE 802.11e QoS mappings across the switching and wireless medium segments. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 05:21: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 FAA28629 for ; Wed, 23 Feb 2005 05:21:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7C00D2061B; Wed, 23 Feb 2005 05:21:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C7F42205F3; Wed, 23 Feb 2005 05:21: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 E6987205F3 for ; Wed, 23 Feb 2005 05:20:59 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 8A91B205E1 for ; Wed, 23 Feb 2005 05:20:57 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1NAHbQ6010622 for ; Wed, 23 Feb 2005 18:17:37 +0800 (SGT) Message-Id: <200502231017.j1NAHbQ6010622@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: 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: AcUZi+YtW7iATNmURHS1bbwi4MFtFAAATAowAAAtkxAAAB1nEAAAP90QAAAVVPAAABWwIAAAEPxQAAAVjZAAACAYoA== X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Additions #19 - CAPWAP Protocol Security 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, 23 Feb 2005 18:20:44 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Additions #19 - CAPWAP Protocol Security Issue: Additional text clarifying mutual authentication of AC and WTPs. Proposed changes are for Objective-5.2.10-'CAPWAP Protocol Security'. Proposed change: Priority: Mandatory Description: (Replace first sentence of first paragraph) The CAPWAP protocol must first ensure that the participating entities - centralized controller and WTPs - are mutually authenticated. Once this has been established, the information exchanges between them must be secured against various security threats. As such, it must provide ...... Protocol Requirement: The CAPWAP protocol must support mutual authentication of WTPs and the centralized controller. It must also ensure that information exchanges between them are secured. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 05:24: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 FAA28964 for ; Wed, 23 Feb 2005 05:24:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 801462062C; Wed, 23 Feb 2005 05:24:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0988520607; Wed, 23 Feb 2005 05:24: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 5948420607 for ; Wed, 23 Feb 2005 05:23:36 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 9F805205F3 for ; Wed, 23 Feb 2005 05:23:33 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1NAKDN8010697 for ; Wed, 23 Feb 2005 18:20:13 +0800 (SGT) Message-Id: <200502231020.j1NAKDN8010697@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: 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: AcUZi+YtW7iATNmURHS1bbwi4MFtFAAATAowAAAtkxAAAB1nEAAAP90QAAAVVPAAABWwIAAAEPxQAAAVjZAAACAYoAAAFaEA X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Additions #20 - Key Distribution 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, 23 Feb 2005 18:23:20 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Additions #20 - Key Distribution Issue: Proposal for key distribution as part of IEEE 802.11i considerations for CAPWAP. Proposed changes are for Objective-5.2.15-'IEEE 802.11i considerations'. Proposed change: Priority: Mandatory Description: (Insert after first paragraph) For key distribution, CAPWAP must be made aware of IEEE 802.11i exchanges and the location of the authenticator and encryption points. This need not be explicit but rather an implicit distinction made during initial configuration of WTPs. This way, CAPWAP can be made to include operations for handling key exchanges in the different cases, i.e. authenticator, encryption at AC or at WTP. Protocol Requirement: The CAPWAP protocol is to be made aware of the location of the IEEE 802.11i authenticator and encryption points. _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 05:35: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 FAA29973 for ; Wed, 23 Feb 2005 05:35:04 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9DD7120635; Wed, 23 Feb 2005 05:35:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 92FD120620; Wed, 23 Feb 2005 05:35: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 B76F320618 for ; Wed, 23 Feb 2005 05:34:30 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 0D98120614 for ; Wed, 23 Feb 2005 05:34:27 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1NAUvcl010980; Wed, 23 Feb 2005 18:30:57 +0800 (SGT) Message-Id: <200502231030.j1NAUvcl010980@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: Cc: , 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: AcUZkzCE3yk3Rl7vSje+goyAgzc/yQ== X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Feedback on Objectives 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, 23 Feb 2005 18:34:03 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dear All, All the proposed changes based on the Chairs' comments have been posted to the list now. Please review them and advise. Also, there were some changes proposed by the authors earlier on in the mailing list. It would be nice to know how folks feel about them also. Since the WG has a tight schedule as a whole, is there a timeline for the Objectives? Looking forward to discussions on the Objectives. Cheers, Saravanan _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 11:25: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 LAA04995 for ; Wed, 23 Feb 2005 11:25:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0448C20663; Wed, 23 Feb 2005 11:25:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 583E82065E; Wed, 23 Feb 2005 11:25: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 952EB2065A for ; Wed, 23 Feb 2005 11:24:49 -0500 (EST) Received: from wanderer.mr.itd.umich.edu (wanderer.mr.itd.umich.edu [141.211.93.146]) by mail.frascone.com (Postfix) with ESMTP id 62D3820657 for ; Wed, 23 Feb 2005 11:24:46 -0500 (EST) Received: from [127.0.0.1] (c-67-182-52-27.client.comcast.net [67.182.52.27]) by wanderer.mr.itd.umich.edu (smtp) with ESMTP id j1NGOark019658 for ; Wed, 23 Feb 2005 11:24:44 -0500 Message-ID: <421CAE34.9020801@umich.edu> From: subrata goswami User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: capwap@frascone.com Subject: Re: [Capwap] Additions #12 - Future Wireless Technologies References: <200502230954.j1N9snp8009869@mailsrv.psl.com.sg> In-Reply-To: <200502230954.j1N9snp8009869@mailsrv.psl.com.sg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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, 23 Feb 2005 08:24:20 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Very sensible requirement ! Saravanan Govindan wrote: >Additions #12 - Future Wireless Technologies > > >Issue: > >Replace subsections as full objectives so they can be reviewed independently. Replace >subsection-5.2.4i-'Enable Support for Future Wireless Technologies' as a separate objective titled >'Support for Future Wireless Technologies'. > > >Proposed change: > >Classification: Architecture > >Priority: Desirable > >Description: > >The rapid pace of technology developments means that new advances need to be catered for in current >analyses. Among these is the support for new wireless technologies within the CAPWAP protocol, such >as IEEE 802.16. The protocol should therefore not rely on specifics of IEEE 802.11 technology. > > > >Protocol Requirement: The CAPWAP protocol must be applicable for IEEE 802.11 and other wireless >technologies. > > >Motivation and Protocol Benefits: > >There are many benefits to an extensible protocol. It allows for application in different networks >and provides greater scope. Furthermore, service providers require WLAN solutions that will be able >to meet current and future market requirements. > > > >Relation to Problem Statement: > >The Problem Statement describes some of the advances taking place in other standards bodies like the >IEEE. It is important for the CAPWAP protocol to reflect the advances and provide a framework in >which they can be supported. > >_______________________________________________ >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 Feb 23 11:55: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 LAA10297 for ; Wed, 23 Feb 2005 11:55:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C87742066D; Wed, 23 Feb 2005 11:55:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 12D9220669; Wed, 23 Feb 2005 11:55: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 EE5232065E for ; Wed, 23 Feb 2005 11:54: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 94D242065A for ; Wed, 23 Feb 2005 11:53:57 -0500 (EST) Message-ID: <04b801c519c8$6a020cc0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Saravanan Govindan" , References: <200502230938.j1N9cid8009350@mailsrv.psl.com.sg> Subject: Re: [Capwap] Additions #9 - Logical Groups 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, 23 Feb 2005 08:54:53 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit What is the definition of a "user group"? jak ----- Original Message ----- From: "Saravanan Govindan" To: Sent: Wednesday, February 23, 2005 1:41 AM Subject: [Capwap] Additions #9 - Logical Groups > Additions #9 - Logical Groups > > Issue: > > Replace subsections as full objectives so they can be reviewed independently > > > Proposed change: > > Replace subsection-5.2.3.i with the following objective > > Classification: Architecture > > Priority: Mandatory > > > Description: > > Large WLAN deployments are complex and expensive. Furthermore, enterprises are under pressure to > improve the efficiency of their expenditures. Shared WLAN deployments, where a number of logical > networks cover a single physical WLAN infrastructure, are increasingly popular because they allow > deployment and management costs to be spread across businesses. Such networks are distinct from > traditional WLANs in which each WTP represents one complete subset of a larger WLAN system. In > shared deployments, each WTP represents a number of subsets of possibly a number of larger WLAN > systems. So with such deployments, WLANs need to be managed in terms of logical groups instead of > physical devices. > > > Protocol Requirement: > > The CAPWAP protocol must be capable of controlling WTPs in terms of logical user groups. > > > > Motivation & Protocol Benefits: > > Commercial realities necessitate that WLANs be manageable in terms of its user groups. This allows > separation of user services and underlying infrastructure management. A protocol that addresses this > need greatly benefits network operators. > > > Relation to Problem Statement: > > This objective addresses the problem of management complexity in terms of costs. Cost complexity is > reduced by sharing WLAN deployments. Consequently, deployment and management cost-efficiencies are > realized. > > > _______________________________________________ > 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 Feb 23 11:59: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 LAA11003 for ; Wed, 23 Feb 2005 11:59:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CE04320661; Wed, 23 Feb 2005 11:59:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 860BA2048D; Wed, 23 Feb 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 2AA702048D for ; Wed, 23 Feb 2005 11:58:30 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 190DB20483 for ; Wed, 23 Feb 2005 11:58:27 -0500 (EST) Message-ID: <04c701c519c9$0b758820$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Saravanan Govindan" , References: <200502230947.j1N9l7Wc009608@mailsrv.psl.com.sg> Subject: Re: [Capwap] Additions #10 - Support for Traffic Separation 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, 23 Feb 2005 08:59:25 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit What is meant by "separation of control and data"? That the AC must be a separate network element from switching and routing equipment that handles user traffic? Or just that the CAPWAP control protocol is only concerned with control, and not with user traffic? There's a big difference between these two. I think this requirement needs to be clearer. jak ----- Original Message ----- From: "Saravanan Govindan" To: Sent: Wednesday, February 23, 2005 1:50 AM Subject: [Capwap] Additions #10 - Support for Traffic Separation > Additions #10 - Support for Traffic Separation > > Issue: > > Include subsection 5.2.3ii-'Mutual separation of Control and Communications' in > Objective-5.2.7-'Support for Traffic Separation'. Proposed changes are to be made to Objective-5.2.7 > > > Proposed change: > > Classification: Operational > > Priority: Mandatory > > Description: > > (Insert after first paragraph) > Furthermore, in the context of shared infrastructure, the mutual separation of data and control also > addresses security concerns. > > (Insert after second paragraph) > And in shared infrastructure WLANs, which may contain traffic belonging to different logical groups > with possibly varying needs, it is important that each group's traffic be separated. > > > > Protocol Requirement: The CAPWAP protocol should separate transport of control and data information. > > > > Motivation and Protocol Benefits: > > (Insert after second paragraph) > Separation of WTP control and data allows for secure realization of shared WLANs. > > > > Relation to Problem Statement: > (Insert after first sentence) > This objectives allows for simplified control as this can be separated from the task of data > transport. > > _______________________________________________ > 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 Feb 23 12:00: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 MAA11248 for ; Wed, 23 Feb 2005 12:00:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E949320672; Wed, 23 Feb 2005 12:00:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id ADE8C2066A; Wed, 23 Feb 2005 12: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 5DCAF2065E for ; Wed, 23 Feb 2005 11:59:47 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 49F232065A for ; Wed, 23 Feb 2005 11:59:44 -0500 (EST) Message-ID: <04ca01c519c9$3957bf60$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Saravanan Govindan" , References: <200502230954.j1N9snp8009869@mailsrv.psl.com.sg> Subject: Re: [Capwap] Additions #12 - Future Wireless Technologies 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, 23 Feb 2005 09:00:41 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit This requirement is really vague. It doesn't really constrain the protocol development at all. What is meant by support for other wireless technologies in addition to 802.11? jak ----- Original Message ----- From: "Saravanan Govindan" To: Sent: Wednesday, February 23, 2005 1:57 AM Subject: [Capwap] Additions #12 - Future Wireless Technologies > Additions #12 - Future Wireless Technologies > > > Issue: > > Replace subsections as full objectives so they can be reviewed independently. Replace > subsection-5.2.4i-'Enable Support for Future Wireless Technologies' as a separate objective titled > 'Support for Future Wireless Technologies'. > > > Proposed change: > > Classification: Architecture > > Priority: Desirable > > Description: > > The rapid pace of technology developments means that new advances need to be catered for in current > analyses. Among these is the support for new wireless technologies within the CAPWAP protocol, such > as IEEE 802.16. The protocol should therefore not rely on specifics of IEEE 802.11 technology. > > > > Protocol Requirement: The CAPWAP protocol must be applicable for IEEE 802.11 and other wireless > technologies. > > > Motivation and Protocol Benefits: > > There are many benefits to an extensible protocol. It allows for application in different networks > and provides greater scope. Furthermore, service providers require WLAN solutions that will be able > to meet current and future market requirements. > > > > Relation to Problem Statement: > > The Problem Statement describes some of the advances taking place in other standards bodies like the > IEEE. It is important for the CAPWAP protocol to reflect the advances and provide a framework in > which they can be supported. > > _______________________________________________ > 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 Feb 23 12:03: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 MAA11744 for ; Wed, 23 Feb 2005 12:03:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 749572066F; Wed, 23 Feb 2005 12:03:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9065F2065A; Wed, 23 Feb 2005 12: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 1C58E2065A for ; Wed, 23 Feb 2005 12:02: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 000F72048D for ; Wed, 23 Feb 2005 12:02:47 -0500 (EST) Message-ID: <04d201c519c9$a64d4590$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Saravanan Govindan" , References: <200502231004.j1NA4w1N010187@mailsrv.psl.com.sg> Subject: Re: [Capwap] Additions #14 - End-user Transparency 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, 23 Feb 2005 09:03:44 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Isn't the issue here the devices and not the users? I think the requirement should be phrased in terms of the device. Sure, users need to deal with any additional software or configuration, but I think what the requirement is trying to get at is that there should be no need to install additional software specifically for CAPWAP on a host with a wireless interface if the interface is linked to a wireless network running CAPWAP. jak ----- Original Message ----- From: "Saravanan Govindan" To: Sent: Wednesday, February 23, 2005 2:08 AM Subject: [Capwap] Additions #14 - End-user Transparency > Additions #14 - End-user Transparency > > > Issue: > > Replace subsections as full objectives so they can be reviewed independently. Replace > subsection-5.2.4iii-'User(Client) Access Requirement' as a separate objective titled 'End-user > Transparency'. > > > Proposed change: > > Classification: Architecture > > > Priority: Mandatory > > > Description: > > The CAPWAP protocol will be used between a centralized controller and a number of WTPs. Its > operations should be independent of the wireless end-user. The end-users should not be required to > be aware of the existence of the CAPWAP protocol. > > > Protocol Requirement: End-users should not be required to recognize the CAPWAP protocol. > > > > Motivation and Protocol Benefits: > > IEEE 802.11 based end-user devices are mature and wide-spread. It would be beneficial for CAPWAP not > to impose new requirements on these numerous devices. > > > Relation to Problem Statement: > > The Problem Statement highlights the challenges faced by large WLANs consisting of many WTPs. Since > it does not refer to end-user operations, this objective is necessary to emphasize this > independence. > > _______________________________________________ > 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 Feb 23 12:06: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 MAA12228 for ; Wed, 23 Feb 2005 12:06:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7295C2067D; Wed, 23 Feb 2005 12:06:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0BDBD2065E; Wed, 23 Feb 2005 12:06: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 26D622065E for ; Wed, 23 Feb 2005 12:05:42 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id B25DC2065A for ; Wed, 23 Feb 2005 12:05:40 -0500 (EST) Message-ID: <04e001c519ca$0d3d0c40$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Saravanan Govindan" , References: <200502231017.j1NAHbQ6010622@mailsrv.psl.com.sg> Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security 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, 23 Feb 2005 09:06:37 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I would additionally suggest adding to this that the key distribution protocol must be designed so as to minimize the possibility of future compromises after the keys are distributed. jak ----- Original Message ----- From: "Saravanan Govindan" To: Sent: Wednesday, February 23, 2005 2:20 AM Subject: [Capwap] Additions #19 - CAPWAP Protocol Security > Additions #19 - CAPWAP Protocol Security > > > Issue: > > Additional text clarifying mutual authentication of AC and WTPs. Proposed changes are for > Objective-5.2.10-'CAPWAP Protocol Security'. > > > Proposed change: > > Priority: Mandatory > > > Description: > > (Replace first sentence of first paragraph) > The CAPWAP protocol must first ensure that the participating entities - centralized controller and > WTPs - are mutually authenticated. Once this has been established, the information exchanges between > them must be secured against various security threats. > > As such, it must provide ...... > > > > Protocol Requirement: > > The CAPWAP protocol must support mutual authentication of WTPs and the centralized controller. It > must also ensure that information exchanges between them are secured. > > _______________________________________________ > 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 Feb 23 12:12: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 MAA13150 for ; Wed, 23 Feb 2005 12:12:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0F7A220680; Wed, 23 Feb 2005 12:12:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 704B020660; Wed, 23 Feb 2005 12:12: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 23CC12067F for ; Wed, 23 Feb 2005 12:11:14 -0500 (EST) Received: from wanderer.mr.itd.umich.edu (wanderer.mr.itd.umich.edu [141.211.93.146]) by mail.frascone.com (Postfix) with ESMTP id E639B2066C for ; Wed, 23 Feb 2005 12:11:12 -0500 (EST) Received: from [127.0.0.1] (c-67-182-52-27.client.comcast.net [67.182.52.27]) by wanderer.mr.itd.umich.edu (smtp) with ESMTP id j1NHB0rk002506 for ; Wed, 23 Feb 2005 12:11:11 -0500 Message-ID: <421CB913.30109@umich.edu> From: subrata goswami User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: capwap@frascone.com Subject: Re: [Capwap] Additions #12 - Future Wireless Technologies References: <200502230954.j1N9snp8009869@mailsrv.psl.com.sg> <04ca01c519c9$3957bf60$016115ac@dcml.docomolabsusa.com> In-Reply-To: <04ca01c519c9$3957bf60$016115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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, 23 Feb 2005 09:10:43 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Seems clear to me that CAPWAP should handle 802.16,802.20 , 802.15.x etc. in addition to 802.11. If CAPWAP is only for 802.11, then it should be addressed in the 802.11 WG in IEEE. Dr. Subrata Goswami James Kempf wrote: >This requirement is really vague. It doesn't really constrain the protocol >development at all. What is meant by support for other wireless technologies >in addition to 802.11? > > jak > > >----- Original Message ----- >From: "Saravanan Govindan" >To: >Sent: Wednesday, February 23, 2005 1:57 AM >Subject: [Capwap] Additions #12 - Future Wireless Technologies > > > > >>Additions #12 - Future Wireless Technologies >> >> >>Issue: >> >>Replace subsections as full objectives so they can be reviewed >> >> >independently. Replace > > >>subsection-5.2.4i-'Enable Support for Future Wireless Technologies' as a >> >> >separate objective titled > > >>'Support for Future Wireless Technologies'. >> >> >>Proposed change: >> >>Classification: Architecture >> >>Priority: Desirable >> >>Description: >> >>The rapid pace of technology developments means that new advances need to >> >> >be catered for in current > > >>analyses. Among these is the support for new wireless technologies within >> >> >the CAPWAP protocol, such > > >>as IEEE 802.16. The protocol should therefore not rely on specifics of >> >> >IEEE 802.11 technology. > > >> >>Protocol Requirement: The CAPWAP protocol must be applicable for IEEE >> >> >802.11 and other wireless > > >>technologies. >> >> >>Motivation and Protocol Benefits: >> >>There are many benefits to an extensible protocol. It allows for >> >> >application in different networks > > >>and provides greater scope. Furthermore, service providers require WLAN >> >> >solutions that will be able > > >>to meet current and future market requirements. >> >> >> >>Relation to Problem Statement: >> >>The Problem Statement describes some of the advances taking place in other >> >> >standards bodies like the > > >>IEEE. It is important for the CAPWAP protocol to reflect the advances and >> >> >provide a framework in > > >>which they can be supported. >> >>_______________________________________________ >>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 Feb 23 12:30: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 MAA16172 for ; Wed, 23 Feb 2005 12:30:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF2A52069B; Wed, 23 Feb 2005 12:30:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4541020695; Wed, 23 Feb 2005 12:30: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 BE29E2067C for ; Wed, 23 Feb 2005 12:29:08 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 7D5A52066C for ; Wed, 23 Feb 2005 12:29:04 -0500 (EST) Message-ID: <052401c519cd$5155ba50$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "subrata goswami" , References: <200502230954.j1N9snp8009869@mailsrv.psl.com.sg> <04ca01c519c9$3957bf60$016115ac@dcml.docomolabsusa.com> <421CB913.30109@umich.edu> Subject: Re: [Capwap] Additions #12 - Future Wireless Technologies 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, 23 Feb 2005 09:30:00 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I'm not arguing with the requirement, I just want it to be more specific. Right now, it isn't. Here is an example of what I think would be a more specific requirement: "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." There may be additional such requirements involving architecture, transport, etc. If we can't get a set of specific requirements that constrain the protocol in this area, then I think this requirement should be dropped. In the past, such vague, motherhood and apple pie requirements have not had much success in passing IESG muster, to say nothing of providing any helpful guidance in protocol development. jak ----- Original Message ----- From: "subrata goswami" To: Sent: Wednesday, February 23, 2005 9:10 AM Subject: Re: [Capwap] Additions #12 - Future Wireless Technologies > Seems clear to me that CAPWAP should handle 802.16,802.20 , 802.15.x > etc. in addition to 802.11. If CAPWAP is only > for 802.11, then it should be addressed in the 802.11 WG in IEEE. > > Dr. Subrata Goswami > > > > > James Kempf wrote: > > >This requirement is really vague. It doesn't really constrain the protocol > >development at all. What is meant by support for other wireless technologies > >in addition to 802.11? > > > > jak > > > > > >----- Original Message ----- > >From: "Saravanan Govindan" > >To: > >Sent: Wednesday, February 23, 2005 1:57 AM > >Subject: [Capwap] Additions #12 - Future Wireless Technologies > > > > > > > > > >>Additions #12 - Future Wireless Technologies > >> > >> > >>Issue: > >> > >>Replace subsections as full objectives so they can be reviewed > >> > >> > >independently. Replace > > > > > >>subsection-5.2.4i-'Enable Support for Future Wireless Technologies' as a > >> > >> > >separate objective titled > > > > > >>'Support for Future Wireless Technologies'. > >> > >> > >>Proposed change: > >> > >>Classification: Architecture > >> > >>Priority: Desirable > >> > >>Description: > >> > >>The rapid pace of technology developments means that new advances need to > >> > >> > >be catered for in current > > > > > >>analyses. Among these is the support for new wireless technologies within > >> > >> > >the CAPWAP protocol, such > > > > > >>as IEEE 802.16. The protocol should therefore not rely on specifics of > >> > >> > >IEEE 802.11 technology. > > > > > >> > >>Protocol Requirement: The CAPWAP protocol must be applicable for IEEE > >> > >> > >802.11 and other wireless > > > > > >>technologies. > >> > >> > >>Motivation and Protocol Benefits: > >> > >>There are many benefits to an extensible protocol. It allows for > >> > >> > >application in different networks > > > > > >>and provides greater scope. Furthermore, service providers require WLAN > >> > >> > >solutions that will be able > > > > > >>to meet current and future market requirements. > >> > >> > >> > >>Relation to Problem Statement: > >> > >>The Problem Statement describes some of the advances taking place in other > >> > >> > >standards bodies like the > > > > > >>IEEE. It is important for the CAPWAP protocol to reflect the advances and > >> > >> > >provide a framework in > > > > > >>which they can be supported. > >> > >>_______________________________________________ > >>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 Feb 23 12:44: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 MAA17783 for ; Wed, 23 Feb 2005 12:44:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AC3A320695; Wed, 23 Feb 2005 12:44:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0842D2066C; Wed, 23 Feb 2005 12: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 DEE9B2066C for ; Wed, 23 Feb 2005 12:43:46 -0500 (EST) Received: from reformers.mr.itd.umich.edu (reformers.mr.itd.umich.edu [141.211.93.147]) by mail.frascone.com (Postfix) with ESMTP id 2D61020634 for ; Wed, 23 Feb 2005 12:43:42 -0500 (EST) Received: from [127.0.0.1] (c-67-182-52-27.client.comcast.net [67.182.52.27]) by reformers.mr.itd.umich.edu (smtp) with ESMTP id j1NHhY52028160 for ; Wed, 23 Feb 2005 12:43:40 -0500 Message-ID: <421CC0B3.2070702@umich.edu> From: subrata goswami User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: capwap@frascone.com Subject: Re: [Capwap] Additions #12 - Future Wireless Technologies References: <200502230954.j1N9snp8009869@mailsrv.psl.com.sg> <04ca01c519c9$3957bf60$016115ac@dcml.docomolabsusa.com> <421CB913.30109@umich.edu> <052401c519cd$5155ba50$016115ac@dcml.docomolabsusa.com> In-Reply-To: <052401c519cd$5155ba50$016115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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, 23 Feb 2005 09:43:15 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit i see, see if you like my rewording inline below. James Kempf wrote: >I'm not arguing with the requirement, I just want it to be more specific. >Right now, it isn't. Here is an example of what I think would be a more >specific requirement: > >"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 entail assigning a layer 2 wireless protocol type and version field to the message PDU. " >There may be additional such requirements involving architecture, transport, >etc. > >If we can't get a set of specific requirements that constrain the protocol >in this area, then I think this requirement should be dropped. In the past, >such vague, motherhood and apple pie requirements have not had much success >in passing IESG muster, to say nothing of providing any helpful guidance in >protocol development. > > jak > >----- Original Message ----- >From: "subrata goswami" >To: >Sent: Wednesday, February 23, 2005 9:10 AM >Subject: Re: [Capwap] Additions #12 - Future Wireless Technologies > > > > >>Seems clear to me that CAPWAP should handle 802.16,802.20 , 802.15.x >>etc. in addition to 802.11. If CAPWAP is only >>for 802.11, then it should be addressed in the 802.11 WG in IEEE. >> >>Dr. Subrata Goswami >> >> >> >> >>James Kempf wrote: >> >> >> >>>This requirement is really vague. It doesn't really constrain the >>> >>> >protocol > > >>>development at all. What is meant by support for other wireless >>> >>> >technologies > > >>>in addition to 802.11? >>> >>> jak >>> >>> >>>----- Original Message ----- >>>From: "Saravanan Govindan" >>>To: >>>Sent: Wednesday, February 23, 2005 1:57 AM >>>Subject: [Capwap] Additions #12 - Future Wireless Technologies >>> >>> >>> >>> >>> >>> >>>>Additions #12 - Future Wireless Technologies >>>> >>>> >>>>Issue: >>>> >>>>Replace subsections as full objectives so they can be reviewed >>>> >>>> >>>> >>>> >>>independently. Replace >>> >>> >>> >>> >>>>subsection-5.2.4i-'Enable Support for Future Wireless Technologies' as a >>>> >>>> >>>> >>>> >>>separate objective titled >>> >>> >>> >>> >>>>'Support for Future Wireless Technologies'. >>>> >>>> >>>>Proposed change: >>>> >>>>Classification: Architecture >>>> >>>>Priority: Desirable >>>> >>>>Description: >>>> >>>>The rapid pace of technology developments means that new advances need >>>> >>>> >to > > >>>> >>>> >>>be catered for in current >>> >>> >>> >>> >>>>analyses. Among these is the support for new wireless technologies >>>> >>>> >within > > >>>> >>>> >>>the CAPWAP protocol, such >>> >>> >>> >>> >>>>as IEEE 802.16. The protocol should therefore not rely on specifics of >>>> >>>> >>>> >>>> >>>IEEE 802.11 technology. >>> >>> >>> >>> >>>>Protocol Requirement: The CAPWAP protocol must be applicable for IEEE >>>> >>>> >>>> >>>> >>>802.11 and other wireless >>> >>> >>> >>> >>>>technologies. >>>> >>>> >>>>Motivation and Protocol Benefits: >>>> >>>>There are many benefits to an extensible protocol. It allows for >>>> >>>> >>>> >>>> >>>application in different networks >>> >>> >>> >>> >>>>and provides greater scope. Furthermore, service providers require WLAN >>>> >>>> >>>> >>>> >>>solutions that will be able >>> >>> >>> >>> >>>>to meet current and future market requirements. >>>> >>>> >>>> >>>>Relation to Problem Statement: >>>> >>>>The Problem Statement describes some of the advances taking place in >>>> >>>> >other > > >>>> >>>> >>>standards bodies like the >>> >>> >>> >>> >>>>IEEE. It is important for the CAPWAP protocol to reflect the advances >>>> >>>> >and > > >>>> >>>> >>>provide a framework in >>> >>> >>> >>> >>>>which they can be supported. >>>> >>>>_______________________________________________ >>>>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 > > > > _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Wed Feb 23 12:49: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 MAA18500 for ; Wed, 23 Feb 2005 12:49:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B95C206A2; Wed, 23 Feb 2005 12:49:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B61AB2067C; Wed, 23 Feb 2005 12: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 A208E2067C for ; Wed, 23 Feb 2005 12:48:17 -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 86B5020634 for ; Wed, 23 Feb 2005 12:48:14 -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 j1NHjqCM013413; Wed, 23 Feb 2005 09:45:52 -0800 (PST) (envelope-from dharkins@trpz.com) Message-Id: <200502231745.j1NHjqCM013413@homebrew.trpz.com> To: "James Kempf" Cc: "Saravanan Govindan" , capwap@frascone.com Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security In-Reply-To: Your message of "Wed, 23 Feb 2005 09:06:37 PST." <04e001c519ca$0d3d0c40$016115ac@dcml.docomolabsusa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13411.1109180752.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, 23 Feb 2005 09:45:52 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The words "key distribution" seem to preclude a key agreement protocol like Diffie-Hellman so I'd suggest not using them. In addition, I'd like to suggest that asymmetric, non-mutual, authentication be possible in the CAPWAP protocol. Not that it's the default or even the mandatory-to-implement, just that it's not forbidden. Dan. On Wed, 23 Feb 2005 09:06:37 PST you wrote > I would additionally suggest adding to this that the key distribution > protocol must be designed so as to minimize the possibility of future > compromises after the keys are distributed. > > jak > > ----- Original Message ----- > From: "Saravanan Govindan" > To: > Sent: Wednesday, February 23, 2005 2:20 AM > Subject: [Capwap] Additions #19 - CAPWAP Protocol Security > > > > Additions #19 - CAPWAP Protocol Security > > > > > > Issue: > > > > Additional text clarifying mutual authentication of AC and WTPs. Proposed > changes are for > > Objective-5.2.10-'CAPWAP Protocol Security'. > > > > > > Proposed change: > > > > Priority: Mandatory > > > > > > Description: > > > > (Replace first sentence of first paragraph) > > The CAPWAP protocol must first ensure that the participating entities - > centralized controller and > > WTPs - are mutually authenticated. Once this has been established, the > information exchanges between > > them must be secured against various security threats. > > > > As such, it must provide ...... > > > > > > > > Protocol Requirement: > > > > The CAPWAP protocol must support mutual authentication of WTPs and the > centralized controller. It > > must also ensure that information exchanges between them are secured. > > > > _______________________________________________ > > 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 Feb 23 12:57: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 MAA19545 for ; Wed, 23 Feb 2005 12:57:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DD70C206A9; Wed, 23 Feb 2005 12:57:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 512BD20693; Wed, 23 Feb 2005 12:57: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 0BCA420693 for ; Wed, 23 Feb 2005 12:56:22 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id E790E20634 for ; Wed, 23 Feb 2005 12:56:19 -0500 (EST) Message-ID: <057b01c519d1$1f9ed790$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "subrata goswami" , References: <200502230954.j1N9snp8009869@mailsrv.psl.com.sg> <04ca01c519c9$3957bf60$016115ac@dcml.docomolabsusa.com> <421CB913.30109@umich.edu> <052401c519cd$5155ba50$016115ac@dcml.docomolabsusa.com> <421CC0B3.2070702@umich.edu> Subject: Re: [Capwap] Additions #12 - Future Wireless Technologies 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, 23 Feb 2005 09:57:13 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > >"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 From capwap-admin@frascone.com Wed Feb 23 12:59: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 MAA19922 for ; Wed, 23 Feb 2005 12:59:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4EF38206AE; Wed, 23 Feb 2005 12:59:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 27FEE206A8; Wed, 23 Feb 2005 12:59: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 6D1A4206A8 for ; Wed, 23 Feb 2005 12:58:18 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 836712069F for ; Wed, 23 Feb 2005 12:58:16 -0500 (EST) Message-ID: <058a01c519d1$65bd2100$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Dan Harkins" Cc: "Saravanan Govindan" , References: <200502231745.j1NHjqCM013413@homebrew.trpz.com> Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security 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, 23 Feb 2005 09:59:12 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Dan, Actually, I wanted to include authenticated Diffie-Hellman. Can you suggest some way that might be changed? Perhaps "negotiation of keying material"? jak ----- Original Message ----- From: "Dan Harkins" To: "James Kempf" Cc: "Saravanan Govindan" ; Sent: Wednesday, February 23, 2005 9:45 AM Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security > The words "key distribution" seem to preclude a key agreement > protocol like Diffie-Hellman so I'd suggest not using them. > > In addition, I'd like to suggest that asymmetric, non-mutual, > authentication be possible in the CAPWAP protocol. Not that it's > the default or even the mandatory-to-implement, just that it's > not forbidden. > > Dan. > > On Wed, 23 Feb 2005 09:06:37 PST you wrote > > I would additionally suggest adding to this that the key distribution > > protocol must be designed so as to minimize the possibility of future > > compromises after the keys are distributed. > > > > jak > > > > ----- Original Message ----- > > From: "Saravanan Govindan" > > To: > > Sent: Wednesday, February 23, 2005 2:20 AM > > Subject: [Capwap] Additions #19 - CAPWAP Protocol Security > > > > > > > Additions #19 - CAPWAP Protocol Security > > > > > > > > > Issue: > > > > > > Additional text clarifying mutual authentication of AC and WTPs. Proposed > > changes are for > > > Objective-5.2.10-'CAPWAP Protocol Security'. > > > > > > > > > Proposed change: > > > > > > Priority: Mandatory > > > > > > > > > Description: > > > > > > (Replace first sentence of first paragraph) > > > The CAPWAP protocol must first ensure that the participating entities - > > centralized controller and > > > WTPs - are mutually authenticated. Once this has been established, the > > information exchanges between > > > them must be secured against various security threats. > > > > > > As such, it must provide ...... > > > > > > > > > > > > Protocol Requirement: > > > > > > The CAPWAP protocol must support mutual authentication of WTPs and the > > centralized controller. It > > > must also ensure that information exchanges between them are secured. > > > > > > _______________________________________________ > > > 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 Feb 23 13:01: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 NAA20340 for ; Wed, 23 Feb 2005 13:01:04 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 95B6A206B4; Wed, 23 Feb 2005 13:01:05 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 529CC206AF; Wed, 23 Feb 2005 13:01: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 E9BE7206AF for ; Wed, 23 Feb 2005 13:00:40 -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 D65FB206AC for ; Wed, 23 Feb 2005 13:00:38 -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 j1NHwIso013593; Wed, 23 Feb 2005 09:58:18 -0800 (PST) (envelope-from dharkins@trpz.com) Message-Id: <200502231758.j1NHwIso013593@homebrew.trpz.com> To: "James Kempf" Cc: "Saravanan Govindan" , capwap@frascone.com Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security In-Reply-To: Your message of "Wed, 23 Feb 2005 09:59:12 PST." <058a01c519d1$65bd2100$016115ac@dcml.docomolabsusa.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13591.1109181498.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, 23 Feb 2005 09:58:18 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) How about "key establishment protocol" that doesn't say how you establish it-- could be an RSA key exchange, or a Diffie-Hellman. Dan. On Wed, 23 Feb 2005 09:59:12 PST you wrote > Dan, > > Actually, I wanted to include authenticated Diffie-Hellman. Can you suggest > some way that might be changed? Perhaps "negotiation of keying material"? > > jak > > > ----- Original Message ----- > From: "Dan Harkins" > To: "James Kempf" > Cc: "Saravanan Govindan" ; > Sent: Wednesday, February 23, 2005 9:45 AM > Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security > > > > The words "key distribution" seem to preclude a key agreement > > protocol like Diffie-Hellman so I'd suggest not using them. > > > > In addition, I'd like to suggest that asymmetric, non-mutual, > > authentication be possible in the CAPWAP protocol. Not that it's > > the default or even the mandatory-to-implement, just that it's > > not forbidden. > > > > Dan. > > > > On Wed, 23 Feb 2005 09:06:37 PST you wrote > > > I would additionally suggest adding to this that the key distribution > > > protocol must be designed so as to minimize the possibility of future > > > compromises after the keys are distributed. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Saravanan Govindan" > > > To: > > > Sent: Wednesday, February 23, 2005 2:20 AM > > > Subject: [Capwap] Additions #19 - CAPWAP Protocol Security > > > > > > > > > > Additions #19 - CAPWAP Protocol Security > > > > > > > > > > > > Issue: > > > > > > > > Additional text clarifying mutual authentication of AC and WTPs. > Proposed > > > changes are for > > > > Objective-5.2.10-'CAPWAP Protocol Security'. > > > > > > > > > > > > Proposed change: > > > > > > > > Priority: Mandatory > > > > > > > > > > > > Description: > > > > > > > > (Replace first sentence of first paragraph) > > > > The CAPWAP protocol must first ensure that the participating > entities - > > > centralized controller and > > > > WTPs - are mutually authenticated. Once this has been established, the > > > information exchanges between > > > > them must be secured against various security threats. > > > > > > > > As such, it must provide ...... > > > > > > > > > > > > > > > Protocol Requirement: > > > > > > > > The CAPWAP protocol must support mutual authentication of WTPs and the > > > centralized controller. It > > > > must also ensure that information exchanges between them are secured. > > > > > > > > _______________________________________________ > > > > 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 Feb 23 13:05: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 NAA21179 for ; Wed, 23 Feb 2005 13:05:05 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3137A206B8; Wed, 23 Feb 2005 13:05:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8852C206B3; Wed, 23 Feb 2005 13:05: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 1F1A0206A1 for ; Wed, 23 Feb 2005 13:04:54 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 0F1FD206A0 for ; Wed, 23 Feb 2005 13:04:52 -0500 (EST) Message-ID: <05ae01c519d2$52771690$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Dan Harkins" Cc: "Saravanan Govindan" , References: <200502231758.j1NHwIso013593@homebrew.trpz.com> Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security 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, 23 Feb 2005 10:05:49 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Sounds fine. jak ----- Original Message ----- From: "Dan Harkins" To: "James Kempf" Cc: "Saravanan Govindan" ; Sent: Wednesday, February 23, 2005 9:58 AM Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security > How about "key establishment protocol" that doesn't say how you > establish it-- could be an RSA key exchange, or a Diffie-Hellman. > > Dan. > > On Wed, 23 Feb 2005 09:59:12 PST you wrote > > Dan, > > > > Actually, I wanted to include authenticated Diffie-Hellman. Can you suggest > > some way that might be changed? Perhaps "negotiation of keying material"? > > > > jak > > > > > > ----- Original Message ----- > > From: "Dan Harkins" > > To: "James Kempf" > > Cc: "Saravanan Govindan" ; > > Sent: Wednesday, February 23, 2005 9:45 AM > > Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security > > > > > > > The words "key distribution" seem to preclude a key agreement > > > protocol like Diffie-Hellman so I'd suggest not using them. > > > > > > In addition, I'd like to suggest that asymmetric, non-mutual, > > > authentication be possible in the CAPWAP protocol. Not that it's > > > the default or even the mandatory-to-implement, just that it's > > > not forbidden. > > > > > > Dan. > > > > > > On Wed, 23 Feb 2005 09:06:37 PST you wrote > > > > I would additionally suggest adding to this that the key distribution > > > > protocol must be designed so as to minimize the possibility of future > > > > compromises after the keys are distributed. > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Saravanan Govindan" > > > > To: > > > > Sent: Wednesday, February 23, 2005 2:20 AM > > > > Subject: [Capwap] Additions #19 - CAPWAP Protocol Security > > > > > > > > > > > > > Additions #19 - CAPWAP Protocol Security > > > > > > > > > > > > > > > Issue: > > > > > > > > > > Additional text clarifying mutual authentication of AC and WTPs. > > Proposed > > > > changes are for > > > > > Objective-5.2.10-'CAPWAP Protocol Security'. > > > > > > > > > > > > > > > Proposed change: > > > > > > > > > > Priority: Mandatory > > > > > > > > > > > > > > > Description: > > > > > > > > > > (Replace first sentence of first paragraph) > > > > > The CAPWAP protocol must first ensure that the participating > > entities - > > > > centralized controller and > > > > > WTPs - are mutually authenticated. Once this has been established, the > > > > information exchanges between > > > > > them must be secured against various security threats. > > > > > > > > > > As such, it must provide ...... > > > > > > > > > > > > > > > > > > > Protocol Requirement: > > > > > > > > > > The CAPWAP protocol must support mutual authentication of WTPs and the > > > > centralized controller. It > > > > > must also ensure that information exchanges between them are secured. > > > > > > > > > > _______________________________________________ > > > > > 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 Feb 24 04:42: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 EAA24339 for ; Thu, 24 Feb 2005 04:42:10 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DFABC2048C; Thu, 24 Feb 2005 04:42:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1998520485; Thu, 24 Feb 2005 04:42: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 3A77020485 for ; Thu, 24 Feb 2005 04:41:59 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id B6F8F2046F for ; Thu, 24 Feb 2005 04:41:56 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1O9cR5u010893; Thu, 24 Feb 2005 17:38:27 +0800 (SGT) Message-Id: <200502240938.j1O9cR5u010893@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: , , Subject: RE: [Capwap] Additions #19 - CAPWAP Protocol Security 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: AcUZ0cVdpJxjVBPtQiKxysjCNnVBXQATGspA In-Reply-To: <05ae01c519d2$52771690$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, 24 Feb 2005 17:41:34 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi James, Dan, Thank you for your suggestions. Summarising the issue, the suggestion is to specify that the CAPWAP protocol must not be compromised after key establishment. Please consider the following text combining suggestions from James and Dan. ---- (Insert in Description) "Additionally, the key establishment protocol for authentication and securing CAPWAP exchanges must be designed to minimize the possibility of future compromises after the keys are established. While mutual authentication is necessary for CAPWAP, the protocol should not prevent the use of asymmetric, non-mutual authentication. The security considerations of such asymmetric authentication are described in the Security Considerations section." ----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 2:06 AM > To: Dan Harkins > Cc: Saravanan Govindan; capwap@frascone.com > Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security > > Sounds fine. > > jak > > ----- Original Message ----- > From: "Dan Harkins" > To: "James Kempf" > Cc: "Saravanan Govindan" ; > Sent: Wednesday, February 23, 2005 9:58 AM > Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security > > > > How about "key establishment protocol" that doesn't say how you > > establish it-- could be an RSA key exchange, or a Diffie-Hellman. > > > > Dan. > > > > On Wed, 23 Feb 2005 09:59:12 PST you wrote > > > Dan, > > > > > > Actually, I wanted to include authenticated > Diffie-Hellman. Can you > suggest > > > some way that might be changed? Perhaps "negotiation of keying > material"? > > > > > > jak > > > > > > > > > ----- Original Message ----- > > > From: "Dan Harkins" > > > To: "James Kempf" > > > Cc: "Saravanan Govindan" ; > > > > Sent: Wednesday, February 23, 2005 9:45 AM > > > Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security > > > > > > > > > > The words "key distribution" seem to preclude a key agreement > > > > protocol like Diffie-Hellman so I'd suggest not using them. > > > > > > > > In addition, I'd like to suggest that asymmetric, non-mutual, > > > > authentication be possible in the CAPWAP protocol. Not that it's > > > > the default or even the mandatory-to-implement, just that it's > > > > not forbidden. > > > > > > > > Dan. > > > > > > > > On Wed, 23 Feb 2005 09:06:37 PST you wrote > > > > > I would additionally suggest adding to this that the key > distribution > > > > > protocol must be designed so as to minimize the possibility of > future > > > > > compromises after the keys are distributed. > > > > > > > > > > jak > > > > > > > > > > ----- Original Message ----- > > > > > From: "Saravanan Govindan" > > > > > To: > > > > > Sent: Wednesday, February 23, 2005 2:20 AM > > > > > Subject: [Capwap] Additions #19 - CAPWAP Protocol Security > > > > > > > > > > > > > > > > Additions #19 - CAPWAP Protocol Security > > > > > > > > > > > > > > > > > > Issue: > > > > > > > > > > > > Additional text clarifying mutual authentication of > AC and WTPs. > > > Proposed > > > > > changes are for > > > > > > Objective-5.2.10-'CAPWAP Protocol Security'. > > > > > > > > > > > > > > > > > > Proposed change: > > > > > > > > > > > > Priority: Mandatory > > > > > > > > > > > > > > > > > > Description: > > > > > > > > > > > > (Replace first sentence of first paragraph) > > > > > > The CAPWAP protocol must first ensure that the participating > > > entities - > > > > > centralized controller and > > > > > > WTPs - are mutually authenticated. Once this has > been established, > the > > > > > information exchanges between > > > > > > them must be secured against various security threats. > > > > > > > > > > > > As such, it must provide ...... > > > > > > > > > > > > > > > > > > > > > > > Protocol Requirement: > > > > > > > > > > > > The CAPWAP protocol must support mutual > authentication of WTPs and > the > > > > > centralized controller. It > > > > > > must also ensure that information exchanges between them are > secured. > > > > > > > > > > > > _______________________________________________ > > > > > > 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 Feb 24 04:44: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 EAA24531 for ; Thu, 24 Feb 2005 04:44:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8F4352049E; Thu, 24 Feb 2005 04:44:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 15B2020492; Thu, 24 Feb 2005 04:44: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 9FB6820486 for ; Thu, 24 Feb 2005 04:43:06 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id C68A12048B for ; Thu, 24 Feb 2005 04:43:03 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1O9dd6I010935; Thu, 24 Feb 2005 17:39:39 +0800 (SGT) Message-Id: <200502240939.j1O9dd6I010935@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: , , Subject: RE: [Capwap] Additions #12 - Future Wireless Technologies 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: AcUZ0KfbHTsrDzejQKWlUafsj1cqogAS4rdg In-Reply-To: <057b01c519d1$1f9ed790$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, 24 Feb 2005 17:42:45 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit 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 From capwap-admin@frascone.com Thu Feb 24 04:44:22 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 EAA24639 for ; Thu, 24 Feb 2005 04:44:22 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA422204C4; Thu, 24 Feb 2005 04:44:19 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7E556204AF; Thu, 24 Feb 2005 04:44:15 -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 C16942048B for ; Thu, 24 Feb 2005 04:43:28 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 66C7F20486 for ; Thu, 24 Feb 2005 04:43:25 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1O9e2vR010958; Thu, 24 Feb 2005 17:40:02 +0800 (SGT) Message-Id: <200502240940.j1O9e2vR010958@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: , Subject: RE: [Capwap] Additions #14 - End-user Transparency 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: AcUZyQthiv1KkCEsRMe9nUS1zJvu0gAV1elw In-Reply-To: <04d201c519c9$a64d4590$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, 24 Feb 2005 17:43:09 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi James, It is true that transparency here is in terms of the 'device'. Consider the following changes to the Additions #14 ---- Title: Wireless Terminal Transparency Description: The CAPWAP protocol will be used between a centralized controller and a number of WTPs. Its operations should be independent of the wireless terminal. The wireless terminals should not be required to be aware of the existence of the CAPWAP protocol. Protocol Requirement: Wireless terminals should not be required to recognize the CAPWAP protocol. Motivation and Protocol Benefits: IEEE 802.11 based wireless terminals are mature and wide-spread. It would be beneficial for CAPWAP not to impose new requirements on these wireless terminals. Relation to Problem Statement: The Problem Statement highlights the challenges faced by large WLANs consisting of many WTPs. Since it does not refer to the operations of wireless terminals, this objective is necessary to emphasize this independence. ----XXXX---- Cheers, Saravanan > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, February 24, 2005 1:04 AM > To: Saravanan Govindan; capwap@frascone.com > Subject: Re: [Capwap] Additions #14 - End-user Transparency > > Isn't the issue here the devices and not the users? I think > the requirement should be phrased in terms of the device. > Sure, users need to deal with any additional software or > configuration, but I think what the requirement is trying to > get at is that there should be no need to install additional > software specifically for CAPWAP on a host with a wireless > interface if the interface is linked to a wireless network > running CAPWAP. > > jak > > ----- Original Message ----- > From: "Saravanan Govindan" > To: > Sent: Wednesday, February 23, 2005 2:08 AM > Subject: [Capwap] Additions #14 - End-user Transparency > > > > Additions #14 - End-user Transparency > > > > > > Issue: > > > > Replace subsections as full objectives so they can be reviewed > independently. Replace > > subsection-5.2.4iii-'User(Client) Access Requirement' as a separate > objective titled 'End-user > > Transparency'. > > > > > > Proposed change: > > > > Classification: Architecture > > > > > > Priority: Mandatory > > > > > > Description: > > > > The CAPWAP protocol will be used between a centralized > controller and a > number of WTPs. Its > > operations should be independent of the wireless end-user. > The end-users > should not be required to > > be aware of the existence of the CAPWAP protocol. > > > > > > Protocol Requirement: End-users should not be required to > recognize the > CAPWAP protocol. > > > > > > > > Motivation and Protocol Benefits: > > > > IEEE 802.11 based end-user devices are mature and > wide-spread. It would be > beneficial for CAPWAP not > > to impose new requirements on these numerous devices. > > > > > > Relation to Problem Statement: > > > > The Problem Statement highlights the challenges faced by large WLANs > consisting of many WTPs. Since > > it does not refer to end-user operations, this objective is > necessary to > emphasize this > > independence. > > > > _______________________________________________ > > 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 Feb 24 04:45: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 EAA24685 for ; Thu, 24 Feb 2005 04:45:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22CF4204F6; Thu, 24 Feb 2005 04:45:09 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 89771204E5; Thu, 24 Feb 2005 04:45: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 461582048B for ; Thu, 24 Feb 2005 04:44:08 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id B63CC2049B for ; Thu, 24 Feb 2005 04:44:04 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1O9eZso010976; Thu, 24 Feb 2005 17:40:37 +0800 (SGT) Message-Id: <200502240940.j1O9eZso010976@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: , Subject: RE: [Capwap] Additions #9 - Logical Groups 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: AcUZx896u3PWuAQbTTym/dePzcV9kwAWXjFQ In-Reply-To: <04b801c519c8$6a020cc0$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, 24 Feb 2005 17:43:48 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi James, A logical division of the physical WTP is referred to as a 'user group'. For example, with virtual APs, each BSSID of a WTP can be construed to be a 'user group'. This way, the WLAN is managed in terms of logical groups instead of physical WTPs. It would be better to avoid references to the term 'user group'. So would 'logical groups' be better? Saravanan > -----Original Message----- > From: James Kempf > Sent: Thursday, February 24, 2005 12:55 AM > To: Saravanan Govindan; capwap@frascone.com > Subject: Re: [Capwap] Additions #9 - Logical Groups > > What is the definition of a "user group"? > > jak > > ----- Original Message ----- > From: "Saravanan Govindan" > To: > Sent: Wednesday, February 23, 2005 1:41 AM > Subject: [Capwap] Additions #9 - Logical Groups > > > > Additions #9 - Logical Groups > > > > Issue: > > > > Replace subsections as full objectives so they can be reviewed > independently > > > > > > Proposed change: > > > > Replace subsection-5.2.3.i with the following objective > > > > Classification: Architecture > > > > Priority: Mandatory > > > > > > Description: > > > > Large WLAN deployments are complex and expensive. > Furthermore, enterprises > are under pressure to > > improve the efficiency of their expenditures. Shared WLAN > deployments, > where a number of logical > > networks cover a single physical WLAN infrastructure, are > increasingly > popular because they allow > > deployment and management costs to be spread across businesses. Such > networks are distinct from > > traditional WLANs in which each WTP represents one complete > subset of a > larger WLAN system. In > > shared deployments, each WTP represents a number of subsets > of possibly a > number of larger WLAN > > systems. So with such deployments, WLANs need to be managed > in terms of > logical groups instead of > > physical devices. > > > > > > Protocol Requirement: > > > > The CAPWAP protocol must be capable of controlling WTPs in terms of > logical user groups. > > > > > > > > Motivation & Protocol Benefits: > > > > Commercial realities necessitate that WLANs be manageable > in terms of its > user groups. This allows > > separation of user services and underlying infrastructure > management. A > protocol that addresses this > > need greatly benefits network operators. > > > > > > Relation to Problem Statement: > > > > This objective addresses the problem of management > complexity in terms of > costs. Cost complexity is > > reduced by sharing WLAN deployments. Consequently, deployment and > management cost-efficiencies are > > realized. > > > > > > _______________________________________________ > > 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 Feb 24 04:45: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 EAA24715 for ; Thu, 24 Feb 2005 04:45:26 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2881720530; Thu, 24 Feb 2005 04:45:26 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0924720510; Thu, 24 Feb 2005 04:45:16 -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 2683C2049E for ; Thu, 24 Feb 2005 04:44:04 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 36EC120486 for ; Thu, 24 Feb 2005 04:44:01 -0500 (EST) Received: from Saravanan ([10.81.113.35]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1O9eZsn010976; Thu, 24 Feb 2005 17:40:35 +0800 (SGT) Message-Id: <200502240940.j1O9eZsn010976@mailsrv.psl.com.sg> From: "Saravanan Govindan" To: , Subject: RE: [Capwap] Additions #10 - Support for Traffic Separation 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: AcUZyHBoLt6ftMcATBKwYiaQRdP+zQAWF87g In-Reply-To: <04c701c519c9$0b758820$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, 24 Feb 2005 17:43:41 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi James, This requirement if for the CAPWAP protocol to deal with control independent of user data traffic. While the control aspects can be used to set up the exchange of user data traffic, the two are to be independent of each other. Cheers, Saravanan > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, February 24, 2005 12:59 AM > To: Saravanan Govindan; capwap@frascone.com > Subject: Re: [Capwap] Additions #10 - Support for Traffic Separation > > What is meant by "separation of control and data"? That the > AC must be a separate network element from switching and > routing equipment that handles user traffic? Or just that the > CAPWAP control protocol is only concerned with control, and > not with user traffic? There's a big difference between these > two. I think this requirement needs to be clearer. > > jak > > ----- Original Message ----- > From: "Saravanan Govindan" > To: > Sent: Wednesday, February 23, 2005 1:50 AM > Subject: [Capwap] Additions #10 - Support for Traffic Separation > > > > Additions #10 - Support for Traffic Separation > > > > Issue: > > > > Include subsection 5.2.3ii-'Mutual separation of Control and > Communications' in > > Objective-5.2.7-'Support for Traffic Separation'. Proposed > changes are to > be made to Objective-5.2.7 > > > > > > Proposed change: > > > > Classification: Operational > > > > Priority: Mandatory > > > > Description: > > > > (Insert after first paragraph) > > Furthermore, in the context of shared infrastructure, the mutual > separation of data and control also > > addresses security concerns. > > > > (Insert after second paragraph) > > And in shared infrastructure WLANs, which may contain > traffic belonging to > different logical groups > > with possibly varying needs, it is important that each > group's traffic be > separated. > > > > > > > > Protocol Requirement: The CAPWAP protocol should separate > transport of > control and data information. > > > > > > > > Motivation and Protocol Benefits: > > > > (Insert after second paragraph) > > Separation of WTP control and data allows for secure > realization of shared > WLANs. > > > > > > > > Relation to Problem Statement: > > (Insert after first sentence) > > This objectives allows for simplified control as this can > be separated > from the task of data > > transport. > > > > _______________________________________________ > > 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 Feb 24 11:34: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 LAA12646 for ; Thu, 24 Feb 2005 11:34:09 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BA60F204BF; Thu, 24 Feb 2005 11:34:09 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9118C204A1; Thu, 24 Feb 2005 11:34: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 1BA44204A1 for ; Thu, 24 Feb 2005 11:33:49 -0500 (EST) Received: from intolerance.mr.itd.umich.edu (intolerance.mr.itd.umich.edu [141.211.14.78]) by mail.frascone.com (Postfix) with ESMTP id DEF0A20497 for ; Thu, 24 Feb 2005 11:33:46 -0500 (EST) Received: from [127.0.0.1] (c-67-182-52-27.client.comcast.net [67.182.52.27]) by intolerance.mr.itd.umich.edu (smtp) with ESMTP id j1OGXSoi005112; Thu, 24 Feb 2005 11:33:41 -0500 Message-ID: <421E01C1.3070401@umich.edu> From: subrata goswami User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Saravanan Govindan Cc: kempf@docomolabs-usa.com, capwap@frascone.com Subject: Re: [Capwap] Additions #12 - Future Wireless Technologies References: <200502240939.j1O9dd6I010935@mailsrv.psl.com.sg> In-Reply-To: <200502240939.j1O9dd6I010935@mailsrv.psl.com.sg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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, 24 Feb 2005 08:33:05 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit 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 From capwap-admin@frascone.com Thu Feb 24 12: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 MAA22767 for ; Thu, 24 Feb 2005 12:56:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AD3172050F; Thu, 24 Feb 2005 12:56:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 949F120500; Thu, 24 Feb 2005 12:56: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 A316120503 for ; Thu, 24 Feb 2005 12:55: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 7DD5D20500 for ; Thu, 24 Feb 2005 12:55:13 -0500 (EST) Message-ID: <081e01c51a9a$2369a8e0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Saravanan Govindan" , References: <200502240940.j1O9eZso010976@mailsrv.psl.com.sg> Subject: Re: [Capwap] Additions #9 - Logical Groups 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, 24 Feb 2005 09:56:09 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I think 'logical groups' would be better. I also think a clear definition and example, such as you give below, is required so people understand what is meant by this term. jak ----- Original Message ----- From: "Saravanan Govindan" To: ; Sent: Thursday, February 24, 2005 1:43 AM Subject: RE: [Capwap] Additions #9 - Logical Groups > Hi James, > > A logical division of the physical WTP is referred to as a 'user group'. For example, with virtual > APs, each BSSID of a WTP can be construed to be a 'user group'. This way, the WLAN is managed in > terms of logical groups instead of physical WTPs. > > It would be better to avoid references to the term 'user group'. So would 'logical groups' be > better? > > Saravanan > > > > > > -----Original Message----- > > From: James Kempf > > Sent: Thursday, February 24, 2005 12:55 AM > > To: Saravanan Govindan; capwap@frascone.com > > Subject: Re: [Capwap] Additions #9 - Logical Groups > > > > What is the definition of a "user group"? > > > > jak > > > > ----- Original Message ----- > > From: "Saravanan Govindan" > > To: > > Sent: Wednesday, February 23, 2005 1:41 AM > > Subject: [Capwap] Additions #9 - Logical Groups > > > > > > > Additions #9 - Logical Groups > > > > > > Issue: > > > > > > Replace subsections as full objectives so they can be reviewed > > independently > > > > > > > > > Proposed change: > > > > > > Replace subsection-5.2.3.i with the following objective > > > > > > Classification: Architecture > > > > > > Priority: Mandatory > > > > > > > > > Description: > > > > > > Large WLAN deployments are complex and expensive. > > Furthermore, enterprises > > are under pressure to > > > improve the efficiency of their expenditures. Shared WLAN > > deployments, > > where a number of logical > > > networks cover a single physical WLAN infrastructure, are > > increasingly > > popular because they allow > > > deployment and management costs to be spread across businesses. Such > > networks are distinct from > > > traditional WLANs in which each WTP represents one complete > > subset of a > > larger WLAN system. In > > > shared deployments, each WTP represents a number of subsets > > of possibly a > > number of larger WLAN > > > systems. So with such deployments, WLANs need to be managed > > in terms of > > logical groups instead of > > > physical devices. > > > > > > > > > Protocol Requirement: > > > > > > The CAPWAP protocol must be capable of controlling WTPs in terms of > > logical user groups. > > > > > > > > > > > > Motivation & Protocol Benefits: > > > > > > Commercial realities necessitate that WLANs be manageable > > in terms of its > > user groups. This allows > > > separation of user services and underlying infrastructure > > management. A > > protocol that addresses this > > > need greatly benefits network operators. > > > > > > > > > Relation to Problem Statement: > > > > > > This objective addresses the problem of management > > complexity in terms of > > costs. Cost complexity is > > > reduced by sharing WLAN deployments. Consequently, deployment and > > management cost-efficiencies are > > > realized. > > > > > > > > > _______________________________________________ > > > 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 Feb 24 13:23: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 NAA26044 for ; Thu, 24 Feb 2005 13:23:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CFAD82053B; Thu, 24 Feb 2005 13:23:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 51C162051C; Thu, 24 Feb 2005 13: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 1EE3320522 for ; Thu, 24 Feb 2005 13:22:19 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 226F42051C for ; Thu, 24 Feb 2005 13:22:16 -0500 (EST) Message-ID: <088901c51a9d$e9e5b420$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Saravanan Govindan" , References: <200502240940.j1O9eZsn010976@mailsrv.psl.com.sg> Subject: Re: [Capwap] Additions #10 - Support for Traffic Separation 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, 24 Feb 2005 10:23:10 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I'm still not sure I understand what constraints this places on the protocol. Does this capture it: "In order to maintain separation of control and data traffic, the CAPWAP protocol is required to define control messages such that they do not involve piggybacking or other combination with terminal data traffic." This would, for example, rule out using an IPv6 Header Option that could be piggybacked on other data traffic (note that I just proposing this as an example). jak ----- Original Message ----- From: "Saravanan Govindan" To: ; Sent: Thursday, February 24, 2005 1:43 AM Subject: RE: [Capwap] Additions #10 - Support for Traffic Separation > Hi James, > > This requirement if for the CAPWAP protocol to deal with control independent of user data traffic. > While the control aspects can be used to set up the exchange of user data traffic, the two are to be > independent of each other. > > Cheers, > > Saravanan > > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Thursday, February 24, 2005 12:59 AM > > To: Saravanan Govindan; capwap@frascone.com > > Subject: Re: [Capwap] Additions #10 - Support for Traffic Separation > > > > What is meant by "separation of control and data"? That the > > AC must be a separate network element from switching and > > routing equipment that handles user traffic? Or just that the > > CAPWAP control protocol is only concerned with control, and > > not with user traffic? There's a big difference between these > > two. I think this requirement needs to be clearer. > > > > jak > > > > ----- Original Message ----- > > From: "Saravanan Govindan" > > To: > > Sent: Wednesday, February 23, 2005 1:50 AM > > Subject: [Capwap] Additions #10 - Support for Traffic Separation > > > > > > > Additions #10 - Support for Traffic Separation > > > > > > Issue: > > > > > > Include subsection 5.2.3ii-'Mutual separation of Control and > > Communications' in > > > Objective-5.2.7-'Support for Traffic Separation'. Proposed > > changes are to > > be made to Objective-5.2.7 > > > > > > > > > Proposed change: > > > > > > Classification: Operational > > > > > > Priority: Mandatory > > > > > > Description: > > > > > > (Insert after first paragraph) > > > Furthermore, in the context of shared infrastructure, the mutual > > separation of data and control also > > > addresses security concerns. > > > > > > (Insert after second paragraph) > > > And in shared infrastructure WLANs, which may contain > > traffic belonging to > > different logical groups > > > with possibly varying needs, it is important that each > > group's traffic be > > separated. > > > > > > > > > > > > Protocol Requirement: The CAPWAP protocol should separate > > transport of > > control and data information. > > > > > > > > > > > > Motivation and Protocol Benefits: > > > > > > (Insert after second paragraph) > > > Separation of WTP control and data allows for secure > > realization of shared > > WLANs. > > > > > > > > > > > > Relation to Problem Statement: > > > (Insert after first sentence) > > > This objectives allows for simplified control as this can > > be separated > > from the task of data > > > transport. > > > > > > _______________________________________________ > > > 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 Feb 24 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 NAA26171 for ; Thu, 24 Feb 2005 13:24:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D8BF22055A; Thu, 24 Feb 2005 13:24:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 14DF420531; Thu, 24 Feb 2005 13: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 936FD20563 for ; Thu, 24 Feb 2005 13:23:25 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 9F6702055B for ; Thu, 24 Feb 2005 13:23:15 -0500 (EST) Message-ID: <089901c51a9e$0dfaeab0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Saravanan Govindan" , , References: <200502240939.j1O9dd6I010935@mailsrv.psl.com.sg> Subject: Re: [Capwap] Additions #12 - Future Wireless Technologies 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, 24 Feb 2005 10:24:11 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Looks fine. jak ----- Original Message ----- From: "Saravanan Govindan" To: ; ; Sent: Thursday, February 24, 2005 1:42 AM Subject: RE: [Capwap] Additions #12 - Future Wireless Technologies > 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 From capwap-admin@frascone.com Thu Feb 24 13:24:31 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 NAA26216 for ; Thu, 24 Feb 2005 13:24:29 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7FAE72062E; Thu, 24 Feb 2005 13:24:30 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6F1D320577; Thu, 24 Feb 2005 13:24:14 -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 409C820522 for ; Thu, 24 Feb 2005 13:23:02 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id E03E72051C for ; Thu, 24 Feb 2005 13:23:00 -0500 (EST) Message-ID: <089401c51a9e$0554b6c0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Saravanan Govindan" , , References: <200502240938.j1O9cR5u010893@mailsrv.psl.com.sg> Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security 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, 24 Feb 2005 10:23:57 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Looks fine. jak ----- Original Message ----- From: "Saravanan Govindan" To: ; ; Sent: Thursday, February 24, 2005 1:41 AM Subject: RE: [Capwap] Additions #19 - CAPWAP Protocol Security > Hi James, Dan, > > Thank you for your suggestions. > > Summarising the issue, the suggestion is to specify that the CAPWAP protocol must not be compromised > after key establishment. > > Please consider the following text combining suggestions from James and Dan. > > ---- > (Insert in Description) > > "Additionally, the key establishment protocol for authentication and securing CAPWAP exchanges must > be designed to minimize the possibility of future compromises after the keys are established. > > While mutual authentication is necessary for CAPWAP, the protocol should not prevent the use of > asymmetric, non-mutual authentication. The security considerations of such asymmetric authentication > are described in the Security Considerations section." > ----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 2:06 AM > > To: Dan Harkins > > Cc: Saravanan Govindan; capwap@frascone.com > > Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security > > > > Sounds fine. > > > > jak > > > > ----- Original Message ----- > > From: "Dan Harkins" > > To: "James Kempf" > > Cc: "Saravanan Govindan" ; > > Sent: Wednesday, February 23, 2005 9:58 AM > > Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security > > > > > > > How about "key establishment protocol" that doesn't say how you > > > establish it-- could be an RSA key exchange, or a Diffie-Hellman. > > > > > > Dan. > > > > > > On Wed, 23 Feb 2005 09:59:12 PST you wrote > > > > Dan, > > > > > > > > Actually, I wanted to include authenticated > > Diffie-Hellman. Can you > > suggest > > > > some way that might be changed? Perhaps "negotiation of keying > > material"? > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Dan Harkins" > > > > To: "James Kempf" > > > > Cc: "Saravanan Govindan" ; > > > > > > Sent: Wednesday, February 23, 2005 9:45 AM > > > > Subject: Re: [Capwap] Additions #19 - CAPWAP Protocol Security > > > > > > > > > > > > > The words "key distribution" seem to preclude a key agreement > > > > > protocol like Diffie-Hellman so I'd suggest not using them. > > > > > > > > > > In addition, I'd like to suggest that asymmetric, non-mutual, > > > > > authentication be possible in the CAPWAP protocol. Not that it's > > > > > the default or even the mandatory-to-implement, just that it's > > > > > not forbidden. > > > > > > > > > > Dan. > > > > > > > > > > On Wed, 23 Feb 2005 09:06:37 PST you wrote > > > > > > I would additionally suggest adding to this that the key > > distribution > > > > > > protocol must be designed so as to minimize the possibility of > > future > > > > > > compromises after the keys are distributed. > > > > > > > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Saravanan Govindan" > > > > > > To: > > > > > > Sent: Wednesday, February 23, 2005 2:20 AM > > > > > > Subject: [Capwap] Additions #19 - CAPWAP Protocol Security > > > > > > > > > > > > > > > > > > > Additions #19 - CAPWAP Protocol Security > > > > > > > > > > > > > > > > > > > > > Issue: > > > > > > > > > > > > > > Additional text clarifying mutual authentication of > > AC and WTPs. > > > > Proposed > > > > > > changes are for > > > > > > > Objective-5.2.10-'CAPWAP Protocol Security'. > > > > > > > > > > > > > > > > > > > > > Proposed change: > > > > > > > > > > > > > > Priority: Mandatory > > > > > > > > > > > > > > > > > > > > > Description: > > > > > > > > > > > > > > (Replace first sentence of first paragraph) > > > > > > > The CAPWAP protocol must first ensure that the participating > > > > entities - > > > > > > centralized controller and > > > > > > > WTPs - are mutually authenticated. Once this has > > been established, > > the > > > > > > information exchanges between > > > > > > > them must be secured against various security threats. > > > > > > > > > > > > > > As such, it must provide ...... > > > > > > > > > > > > > > > > > > > > > > > > > > > Protocol Requirement: > > > > > > > > > > > > > > The CAPWAP protocol must support mutual > > authentication of WTPs and > > the > > > > > > centralized controller. It > > > > > > > must also ensure that information exchanges between them are > > secured. > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 Feb 24 13:24:48 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 NAA26252 for ; Thu, 24 Feb 2005 13:24:48 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3AB9A2055B; Thu, 24 Feb 2005 13:24:49 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 377E920529; Thu, 24 Feb 2005 13:24:25 -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 6E7CF2053A for ; Thu, 24 Feb 2005 13:23: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 A419920565 for ; Thu, 24 Feb 2005 13:23:26 -0500 (EST) Message-ID: <089d01c51a9e$146bc810$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Saravanan Govindan" , References: <200502240940.j1O9e2vR010958@mailsrv.psl.com.sg> Subject: Re: [Capwap] Additions #14 - End-user Transparency 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, 24 Feb 2005 10:24:22 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Looks fine. jak ----- Original Message ----- From: "Saravanan Govindan" To: ; Sent: Thursday, February 24, 2005 1:43 AM Subject: RE: [Capwap] Additions #14 - End-user Transparency > Hi James, > > It is true that transparency here is in terms of the 'device'. > > Consider the following changes to the Additions #14 > > ---- > Title: Wireless Terminal Transparency > > Description: The CAPWAP protocol will be used between a centralized controller and a number of WTPs. > Its operations should be independent of the wireless terminal. The wireless terminals should not be > required to be aware of the existence of the CAPWAP protocol. > > Protocol Requirement: Wireless terminals should not be required to recognize the > CAPWAP protocol. > > Motivation and Protocol Benefits: IEEE 802.11 based wireless terminals are mature and wide-spread. > It would be beneficial for CAPWAP not to impose new requirements on these wireless terminals. > > Relation to Problem Statement: The Problem Statement highlights the challenges faced by large WLANs > consisting of many WTPs. Since it does not refer to the operations of wireless terminals, this > objective is necessary to emphasize this independence. > ----XXXX---- > > Cheers, > > Saravanan > > > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Thursday, February 24, 2005 1:04 AM > > To: Saravanan Govindan; capwap@frascone.com > > Subject: Re: [Capwap] Additions #14 - End-user Transparency > > > > Isn't the issue here the devices and not the users? I think > > the requirement should be phrased in terms of the device. > > Sure, users need to deal with any additional software or > > configuration, but I think what the requirement is trying to > > get at is that there should be no need to install additional > > software specifically for CAPWAP on a host with a wireless > > interface if the interface is linked to a wireless network > > running CAPWAP. > > > > jak > > > > ----- Original Message ----- > > From: "Saravanan Govindan" > > To: > > Sent: Wednesday, February 23, 2005 2:08 AM > > Subject: [Capwap] Additions #14 - End-user Transparency > > > > > > > Additions #14 - End-user Transparency > > > > > > > > > Issue: > > > > > > Replace subsections as full objectives so they can be reviewed > > independently. Replace > > > subsection-5.2.4iii-'User(Client) Access Requirement' as a separate > > objective titled 'End-user > > > Transparency'. > > > > > > > > > Proposed change: > > > > > > Classification: Architecture > > > > > > > > > Priority: Mandatory > > > > > > > > > Description: > > > > > > The CAPWAP protocol will be used between a centralized > > controller and a > > number of WTPs. Its > > > operations should be independent of the wireless end-user. > > The end-users > > should not be required to > > > be aware of the existence of the CAPWAP protocol. > > > > > > > > > Protocol Requirement: End-users should not be required to > > recognize the > > CAPWAP protocol. > > > > > > > > > > > > Motivation and Protocol Benefits: > > > > > > IEEE 802.11 based end-user devices are mature and > > wide-spread. It would be > > beneficial for CAPWAP not > > > to impose new requirements on these numerous devices. > > > > > > > > > Relation to Problem Statement: > > > > > > The Problem Statement highlights the challenges faced by large WLANs > > consisting of many WTPs. Since > > > it does not refer to end-user operations, this objective is > > necessary to > > emphasize this > > > independence. > > > > > > _______________________________________________ > > > 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 Feb 24 13:26: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 NAA26473 for ; Thu, 24 Feb 2005 13:26:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D63520558; Thu, 24 Feb 2005 13:26:10 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 589C520594; Thu, 24 Feb 2005 13:26: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 642D220617 for ; Thu, 24 Feb 2005 13:25:11 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 2F714205E8 for ; Thu, 24 Feb 2005 13:24:56 -0500 (EST) Message-ID: <08a401c51a9e$4a479f90$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "subrata goswami" , "Saravanan Govindan" Cc: References: <200502240939.j1O9dd6I010935@mailsrv.psl.com.sg> <421E01C1.3070401@umich.edu> 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) Subject: [Capwap] Additional Requirement? 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, 24 Feb 2005 10:25:52 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit 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 From capwap-admin@frascone.com Thu Feb 24 16:58: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 QAA26846 for ; Thu, 24 Feb 2005 16:58:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CBDBF2065D; Thu, 24 Feb 2005 16:58:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 335EC2064C; Thu, 24 Feb 2005 16:58: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 EA0142064C for ; Thu, 24 Feb 2005 16:57:07 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by mail.frascone.com (Postfix) with ESMTP id 794A72064B for ; Thu, 24 Feb 2005 16:57:04 -0500 (EST) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1OLv1p20613; Thu, 24 Feb 2005 23:57:02 +0200 (EET) X-Scanned: Thu, 24 Feb 2005 23:56:10 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j1OLuAP0013337; Thu, 24 Feb 2005 23:56:10 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00022ub3; Thu, 24 Feb 2005 23:56:01 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 j1OLu0M26302; Thu, 24 Feb 2005 23:56:00 +0200 (EET) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 24 Feb 2005 15:55:56 -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: Agenda items for IETF #62 in Minneapolis Thread-Index: AcUau521eXThvcCSQSKyYUyQMsYbYQ== From: To: Cc: X-OriginalArrivalTime: 24 Feb 2005 21:55:56.0845 (UTC) FILETIME=[9E636DD0:01C51ABB] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] Agenda items for IETF #62 in 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: Thu, 24 Feb 2005 13:55:55 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable CAPWAP agenda items for IETF #62 We currently have 2 presentations confirmed: Saravanan Govindan: draft-ietf-capwap-objectives review and open issues Pat Calhoun: LWAPP update Our primary goal for IETF 62 is to discuss and resolve open issues on = the Objectives draft. Please send any request for agenda slots. We tentatively have our = meeting set for Monday afternoon. Thanks. Dorothy _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Thu Feb 24 22:13: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 WAA25979 for ; Thu, 24 Feb 2005 22:13:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 94D3C2024F; Thu, 24 Feb 2005 22:13:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7E2F4202CA; Thu, 24 Feb 2005 22:13: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 A42B3202CA for ; Thu, 24 Feb 2005 22:12:29 -0500 (EST) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 88E822024F for ; Thu, 24 Feb 2005 22:12:26 -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 j1P32PaB010504 for ; Thu, 24 Feb 2005 22:02:25 -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 j1P32NaB010483 for ; Thu, 24 Feb 2005 22:02:24 -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] Additions #20 - Key Distribution Message-ID: <5844A41F4E146044A2E8356C6328588007E3B661@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] Additions #20 - Key Distribution Thread-Index: AcUZi+YtW7iATNmURHS1bbwi4MFtFAAATAowAAAtkxAAAB1nEAAAP90QAAAVVPAAABWwIAAAEPxQAAAVjZAAACAYoAAAFaEAAFVIZqA= From: "Sadot, Emek (Emek)" To: "Saravanan Govindan" , 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, 24 Feb 2005 22:12:02 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Saravanan, Clearly the location of the authenticator should be known to the CAPWAP, however the linkage between the CAPWAP and the 802.11i, and exchanges protocol in particular, is not clear to me. In my mind the authentication protocol should not be tied with the CAPWAP protocol nor the specific exchanges protocol. 802.11i is one instance, other authentication protocol may become handy. Emek -----Original Message----- From: capwap-admin@frascone.com [mailto:capwap-admin@frascone.com] On Behalf Of Saravanan Govindan Sent: Wednesday, February 23, 2005 5:23 AM To: capwap@frascone.com Subject: [Capwap] Additions #20 - Key Distribution Additions #20 - Key Distribution Issue:=20 Proposal for key distribution as part of IEEE 802.11i considerations for CAPWAP. Proposed changes are for Objective-5.2.15-'IEEE 802.11i considerations'. Proposed change:=20 =20 Priority: Mandatory Description:=20 (Insert after first paragraph) For key distribution, CAPWAP must be made aware of IEEE 802.11i exchanges and the location of the authenticator and encryption points. This need not be explicit but rather an implicit distinction made during initial configuration of WTPs. This way, CAPWAP can be made to include operations for handling key exchanges in the different cases, i.e. authenticator, encryption at AC or at WTP. Protocol Requirement: The CAPWAP protocol is to be made aware of the location of the IEEE 802.11i authenticator and encryption points. _______________________________________________ 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 Feb 24 22:43: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 WAA28329 for ; Thu, 24 Feb 2005 22:43:06 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E924B20416; Thu, 24 Feb 2005 22:43:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 130352031A; Thu, 24 Feb 2005 22:43: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 BD23D2031A for ; Thu, 24 Feb 2005 22:42:43 -0500 (EST) Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by mail.frascone.com (Postfix) with ESMTP id C0D2B20313 for ; Thu, 24 Feb 2005 22:42:40 -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 j1P3eUox005511 for ; Thu, 24 Feb 2005 22:40:30 -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 j1P3eTox005504 for ; Thu, 24 Feb 2005 22:40:29 -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_01C51AEC.00F8A888" Subject: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details Message-ID: <5844A41F4E146044A2E8356C6328588007E3B66A@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details Thread-Index: AcUa7AyyjArhUAV7QE2IkaTbgWPvNw== From: "Sadot, Emek (Emek)" 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: Thu, 24 Feb 2005 22:42:18 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C51AEC.00F8A888 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "5.1.1 Objective Details 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 WTPs using a single CAPWAP protocol. Integral support for these designs comprises a number of protocol aspects.=20 i. Functionality negotiations between WLAN controller and WTPs Local MAC and split MAC designs differ in the degree of IEEE 802.11 MAC functionalities that each type of WTP realizes. The CAPWAP protocol should allow WLAN controllers to determine the functionalities of different WTPs as a first step in controlling them." "determine the functionalities of different WTPs" - we should not assume that all Local and Split WTP vendors will select the same set of atomic 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 hundreds (ok, ok, so I am exaggerating a bit) of instances per each group (Local and Split). =20 Regards, Emek Sadot System Architect Group Avaya Communication 732-852-2367 =20 ------_=_NextPart_001_01C51AEC.00F8A888 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
"5.1.1  Objective Details


   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 WTPs using a
   single CAPWAP protocol.  Integral support for these designs comprises
   a number of protocol aspects. 

   i.  Functionality negotiations =
between WLAN controller and WTPs

   Local MAC and split MAC designs differ in the degree of IEEE 802.11
   MAC functionalities that each type of WTP realizes.  The CAPWAP
   protocol should allow WLAN controllers to determine the
   functionalities of different WTPs as a first step in controlling
   them."
"determine the=20 functionalities of different WTPs" - we should not assume that all Local = and=20 Split WTP vendors will select the same set of atomic = components,=20 t.b.d. by the APF WG - result in one instance of Local and one = per=20 Split WTP. On the other hand we should be careful = allowing any=20 permutation of the atomic APF components which could lead=20 into hundreds (ok, ok, so I am exaggerating a bit) = of instances=20 per each group (Local and Split).
 

Regards,

Emek Sadot

System Architect = Group

Avaya = Communication

732-852-2367

 
------_=_NextPart_001_01C51AEC.00F8A888-- _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Feb 25 12:46:20 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 MAA12543 for ; Fri, 25 Feb 2005 12:46:19 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 40E7B2065C; Fri, 25 Feb 2005 12:46:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1F7982064F; Fri, 25 Feb 2005 12:46: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 49F54205EB for ; Fri, 25 Feb 2005 12:45:32 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 5C00E204A8 for ; Fri, 25 Feb 2005 12:45:29 -0500 (EST) Message-ID: <0a7301c51b61$f0f73e40$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Sadot, Emek (Emek)" , References: <5844A41F4E146044A2E8356C6328588007E3B66A@nj7460avexu2.global.avaya.com> 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: Fri, 25 Feb 2005 09:46:24 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Emek/All, Thanx for bringing this up. This objective is something I have been wondering about. 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 and WTP more complicated, complicating the configuration and management. I know that the vendors are basically not in agreement about the right technical solution, and that some vendors are providing split MAC while others are providing local, so I'm afraid any attempt at an objective discussion on this will degenerate into both sides supporting their particular product offering with material from their respective marketing departments. The other problem with trying to choose is that I can think of good technical reasons in support of both alternatives. I can also think of good nontechnical reasons to choose one or the other. One way we could solve this problem is to structure the protocol such that the two choices are clearly separate and let the market decide which way to go.That way, if CAPWAP is progressed to Draft Standard, if one or the other fails to achieve widespread deployment, the alternative that is not deployed can be EOLed. There are other possible ways to cleanly separate the two, but they involve making some kind of value judgement that, I'm sure, one side or the other will object to based on the perceived impact of that judgement on their market capture potential. jak ----- 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 "5.1.1 Objective Details 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 WTPs using a single CAPWAP protocol. Integral support for these designs comprises a number of protocol aspects. i. Functionality negotiations between WLAN controller and WTPs Local MAC and split MAC designs differ in the degree of IEEE 802.11 MAC functionalities that each type of WTP realizes. The CAPWAP protocol should allow WLAN controllers to determine the functionalities of different WTPs as a first step in controlling them." "determine the functionalities of different WTPs" - we should not assume that all Local and Split WTP vendors will select the same set of atomic 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 hundreds (ok, ok, so I am exaggerating a bit) of instances per each group (Local and Split). Regards, Emek Sadot System Architect Group Avaya Communication 732-852-2367 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Fri Feb 25 22:35: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 WAA29166 for ; Fri, 25 Feb 2005 22:35:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 585DF2043A; Fri, 25 Feb 2005 22:35:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C9684203E7; Fri, 25 Feb 2005 22:35: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 2266120397 for ; Fri, 25 Feb 2005 22:34:43 -0500 (EST) Received: from tierw.net.avaya.com (tierw.net.avaya.com [198.152.13.100]) by mail.frascone.com (Postfix) with ESMTP id 4A7A5202DC for ; Fri, 25 Feb 2005 22:34:41 -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 j1Q3OcaB028348 for ; Fri, 25 Feb 2005 22:24:38 -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 j1Q3ObaB028315 for ; Fri, 25 Feb 2005 22:24:37 -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: <5844A41F4E146044A2E8356C6328588007E3BB3D@nj7460avexu2.global.avaya.com> Thread-Topic: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details Thread-Index: AcUbYcAihNhSG3c0RMqTxMWjNdzcjAAUKSdg From: "Sadot, Emek (Emek)" To: "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: Fri, 25 Feb 2005 22:34:14 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable 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? My concern lies at the AC side and the complexity involved. Emek -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 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 Emek/All, Thanx for bringing this up. This objective is something I have been wondering about. 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 and WTP more complicated, complicating the configuration and management. I know that the vendors are basically not in agreement about the right technical solution, and that some vendors are providing split MAC while others are providing local, so I'm afraid any attempt at an objective discussion on this will degenerate into both sides supporting their particular product offering with material from their respective marketing departments. The other problem with trying to choose is that I can think of good technical reasons in support of both alternatives. I can also think of good nontechnical reasons to choose one or the other. One way we could solve this problem is to structure the protocol such that the two choices are clearly separate and let the market decide which way to go.That way, if CAPWAP is progressed to Draft Standard, if one or the other fails to achieve widespread deployment, the alternative that is not deployed can be EOLed. There are other possible ways to cleanly separate the two, but they involve making some kind of value judgement that, I'm sure, one side or the other will object to based on the perceived impact of that judgement on their market capture potential. jak ----- 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 "5.1.1 Objective Details 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 WTPs using a single CAPWAP protocol. Integral support for these designs comprises a number of protocol aspects. i. Functionality negotiations between WLAN controller and WTPs Local MAC and split MAC designs differ in the degree of IEEE 802.11 MAC functionalities that each type of WTP realizes. The CAPWAP protocol should allow WLAN controllers to determine the functionalities of different WTPs as a first step in controlling them." "determine the functionalities of different WTPs" - we should not assume that all Local and Split WTP vendors will select the same set of atomic 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 hundreds (ok, ok, so I am exaggerating a bit) of instances per each group (Local and Split). Regards, Emek Sadot System Architect Group Avaya Communication 732-852-2367 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sat Feb 26 22:30: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 WAA22442 for ; Sat, 26 Feb 2005 22:30:10 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9445D1FE0B; Sat, 26 Feb 2005 22:30:08 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9AE091FD6C; Sat, 26 Feb 2005 22:30: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 69A801FD61 for ; Sat, 26 Feb 2005 22:29:25 -0500 (EST) Received: from huawei.com (szxga03-in.huawei.com [61.144.161.55]) by mail.frascone.com (Postfix) with ESMTP id C6D171FC5F for ; Sat, 26 Feb 2005 22:29:17 -0500 (EST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICJ00IREWDIGV@szxga03-in.huawei.com> for capwap@frascone.com; Sun, 27 Feb 2005 11:29:43 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICJ0073IWDIFF@szxga03-in.huawei.com> for capwap@frascone.com; Sun, 27 Feb 2005 11:29:42 +0800 (CST) Received: from jys3101091805 ([210.21.209.233]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ICJ00AFYWGAIL@szxml02-in.huawei.com> for capwap@frascone.com; Sun, 27 Feb 2005 11:31:22 +0800 (CST) From: Yao Zhong Hui To: capwap@frascone.com Message-id: <00a201c518c5$c3b39f80$870aa70a@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: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20050226170002.21051.87541.Mailman@xavier> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [Capwap] RE: CAPWAP Objectives rev00 - 5.1.1 Objective Details (Zhonghui Yao) 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, 22 Feb 2005 18:03:20 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7BIT Hello Jak, Emek and all, It is very valuable if we can manage both split and local WTPs in one network with uniform approach. Local WTPs have the largest amount in the market and Split WTPs have been growing quickly, So it is a factual requirement that Local WTPs and Split WTPs co-exist in one network. In fact, the difference of WTPs is not only between SPIT and LOCAL, but also among Split WTPs from different vendors. So, following the objectives should be the CAPWAP functions definition. I think we can summarize the CAPWAP functions into two groups: (1) Wireless MAC/PHY-layer related management and control This group functions may include such as BEACON parameter setting, MAC-layer management frame transfer etc. (2) Wireless MAC/PHY-layer independent management and control This group functions may include firmware management, data plane management, User Authentication and Key distribution, etc. Thanks, Zhonghui Yao Huawei ----- Original Message ----- From: To: Sent: Sunday, February 27, 2005 1:00 AM Subject: Capwap digest, Vol 1 #342 - 2 msgs > Send Capwap mailing list submissions to > capwap@frascone.com > > 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 > > You can reach the person managing the list at > capwap-admin@frascone.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Capwap digest..." > > > Today's Topics: > > 1. Re: CAPWAP Objectives rev00 - 5.1.1 Objective Details (James Kempf) > 2. RE: CAPWAP Objectives rev00 - 5.1.1 Objective Details (Sadot, Emek (Emek)) > > --__--__-- > > Message: 1 > From: "James Kempf" > To: "Sadot, Emek (Emek)" , > Subject: Re: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details > Date: Fri, 25 Feb 2005 09:46:24 -0800 > > Emek/All, > > Thanx for bringing this up. This objective is something I have been > wondering about. > > 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 and WTP more > complicated, complicating the configuration and management. I know that the > vendors are basically not in agreement about the right technical solution, > and that some vendors are providing split MAC while others are providing > local, so I'm afraid any attempt at an objective discussion on this will > degenerate into both sides supporting their particular product offering with > material from their respective marketing departments. The other problem with > trying to choose is that I can think of good technical reasons in support of > both alternatives. I can also think of good nontechnical reasons to choose > one or the other. > > One way we could solve this problem is to structure the protocol such that > the two choices are clearly separate and let the market decide which way to > go.That way, if CAPWAP is progressed to Draft Standard, if one or the other > fails to achieve widespread deployment, the alternative that is not deployed > can be EOLed. > > There are other possible ways to cleanly separate the two, but they involve > making some kind of value judgement that, I'm sure, one side or the other > will object to based on the perceived impact of that judgement on their > market capture potential. > > jak > > > ----- 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 > > > "5.1.1 Objective Details > > > 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 WTPs using a > single CAPWAP protocol. Integral support for these designs comprises > a number of protocol aspects. > i. Functionality negotiations between WLAN controller and WTPs Local MAC > and split MAC designs differ in the degree of IEEE 802.11 MAC > functionalities that each type of WTP realizes. The CAPWAP protocol > should allow WLAN controllers to determine the functionalities of > different WTPs as a first step in controlling them." > "determine the functionalities of different WTPs" - we should not assume > that all Local and Split WTP vendors will select the same set of atomic > 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 hundreds > (ok, ok, so I am exaggerating a bit) of instances per each group (Local > and Split). > > > Regards, > > Emek Sadot > > System Architect Group > > Avaya Communication > > 732-852-2367 > > > > > > --__--__-- > > Message: 2 > Subject: RE: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details > Date: Fri, 25 Feb 2005 22:34:14 -0500 > From: "Sadot, Emek (Emek)" > To: "James Kempf" , > > 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? > > My concern lies at the AC side and the complexity involved. > > Emek > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > 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 > > Emek/All, > > Thanx for bringing this up. This objective is something I have been > wondering about. > > 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 and > WTP more complicated, complicating the configuration and management. I > know that the vendors are basically not in agreement about the right > technical solution, and that some vendors are providing split MAC while > others are providing local, so I'm afraid any attempt at an objective > discussion on this will degenerate into both sides supporting their > particular product offering with material from their respective > marketing departments. The other problem with trying to choose is that I > can think of good technical reasons in support of both alternatives. I > can also think of good nontechnical reasons to choose one or the other. > > One way we could solve this problem is to structure the protocol such > that the two choices are clearly separate and let the market decide > which way to go.That way, if CAPWAP is progressed to Draft Standard, if > one or the other fails to achieve widespread deployment, the alternative > that is not deployed can be EOLed. > > There are other possible ways to cleanly separate the two, but they > involve making some kind of value judgement that, I'm sure, one side or > the other will object to based on the perceived impact of that judgement > on their market capture potential. > > jak > > > ----- 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 > > > "5.1.1 Objective Details > > > 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 WTPs using a > single CAPWAP protocol. Integral support for these designs comprises > a number of protocol aspects. > i. Functionality negotiations between WLAN controller and WTPs Local MAC > and split MAC designs differ in the degree of IEEE 802.11 MAC > functionalities that each type of WTP realizes. The CAPWAP protocol > should allow WLAN controllers to determine the functionalities of > different WTPs as a first step in controlling them." > "determine the functionalities of different WTPs" - we should not assume > that all Local and Split WTP vendors will select the same set of atomic > 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 hundreds > (ok, ok, so I am exaggerating a bit) of instances per each group (Local > and Split). > > > Regards, > > Emek Sadot > > System Architect Group > > Avaya Communication > > 732-852-2367 > > > > > > > > --__--__-- > > _______________________________________________ > Capwap mailing list > Capwap@frascone.com > http://mail.frascone.com/mailman/listinfo/capwap > > > End of Capwap Digest _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Sun Feb 27 22:06: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 WAA01231 for ; Sun, 27 Feb 2005 22:06:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6062A20427; Sun, 27 Feb 2005 22:06:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D10912041D; Sun, 27 Feb 2005 22:06: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 DF0952041D for ; Sun, 27 Feb 2005 22:05:47 -0500 (EST) Received: from mailsrv.psl.com.sg (mailsrv.psl.com.sg [202.14.153.3]) by mail.frascone.com (Postfix) with ESMTP id 0670720418 for ; Sun, 27 Feb 2005 22:05:43 -0500 (EST) Received: from Palpatine ([10.81.113.73]) by mailsrv.psl.com.sg (8.13.1/8.13.1) with ESMTP id j1S31juX013675; Mon, 28 Feb 2005 11:01:59 +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: <009301c51d42$56e56b50$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: <5844A41F4E146044A2E8356C6328588007E3BB3D@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: Mon, 28 Feb 2005 11:05:04 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable 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=20 > [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=20 > Objective Details >=20 >=20 > The other side of the coin is the question how many=20 > permutations would the protocol allows within each group -=20 > Split and Local. E.g. does the protocol allows the existent=20 > of several distinct Split WTPs each with different (APF) set=20 > 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]=20 > Sent: Friday, February 25, 2005 12:46 PM > To: Sadot, Emek (Emek); capwap@frascone.com > Subject: Re: [Capwap] CAPWAP Objectives rev00 - 5.1.1=20 > Objective Details >=20 > Emek/All, >=20 > Thanx for bringing this up. This objective is something I=20 > have been wondering about. >=20 > From a service provider perspective, having support for both=20 > local and split MAC does not seem to be such a good idea. It=20 > makes both the AC and WTP more complicated, complicating the=20 > configuration and management. I know that the vendors are=20 > basically not in agreement about the right technical=20 > solution, and that some vendors are providing split MAC while=20 > others are providing local, so I'm afraid any attempt at an=20 > objective discussion on this will degenerate into both sides=20 > supporting their particular product offering with material=20 > from their respective marketing departments. The other=20 > problem with trying to choose is that I can think of good=20 > technical reasons in support of both alternatives. I can also=20 > think of good nontechnical 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=20 > let the market decide which way to go.That way, if CAPWAP is=20 > progressed to Draft Standard, if one or the other fails to=20 > achieve widespread deployment, the alternative that is not=20 > deployed can be EOLed. >=20 > There are other possible ways to cleanly separate the two,=20 > but they involve making some kind of value judgement that,=20 > I'm sure, one side or the other will object to based on the=20 > perceived impact of that 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=20 > 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 a > single CAPWAP protocol. Integral support for these=20 > designs comprises > a number of protocol aspects. > i. Functionality negotiations between WLAN controller and=20 > WTPs Local MAC and split MAC designs differ in the degree of=20 > IEEE 802.11 MAC functionalities that each type of WTP=20 > realizes. The CAPWAP protocol should allow WLAN controllers=20 > to determine the functionalities of different WTPs as a first=20 > step in controlling them." "determine the functionalities of=20 > different WTPs" - we should not assume that all Local and=20 > Split WTP vendors will select the same set of atomic=20 > components, t.b.d. by the APF WG - result in one instance of=20 > Local and one per Split WTP. On the other hand we should be=20 > careful allowing any permutation of the atomic APF components=20 > which could lead into hundreds (ok, ok, so I am exaggerating=20 > a bit) of instances per each 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 Mon Feb 28 12:44: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 MAA14617 for ; Mon, 28 Feb 2005 12:44:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 73896202E1; Mon, 28 Feb 2005 12:44:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C4F8C1FC64; Mon, 28 Feb 2005 12:44: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 829931FC64 for ; Mon, 28 Feb 2005 12:43: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 D729D1FC62 for ; Mon, 28 Feb 2005 12:43:52 -0500 (EST) Message-ID: <001901c51dbd$36bd3080$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Sadot, Emek (Emek)" , References: <5844A41F4E146044A2E8356C6328588007E3BB3D@nj7460avexu2.global.avaya.com> 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: Mon, 28 Feb 2005 09:44:50 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Emek, What I meant by "clearly separated" was that the AC must decide either to support split MAC or local. Allowing the WTPs attached to one AC to have a mix would, in my opinion, lead to increased management complexity for very little gain. jak ----- Original Message ----- From: "Sadot, Emek (Emek)" To: "James Kempf" ; Sent: Friday, February 25, 2005 7:34 PM Subject: RE: [Capwap] CAPWAP Objectives rev00 - 5.1.1 Objective Details 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? My concern lies at the AC side and the complexity involved. Emek -----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 Emek/All, Thanx for bringing this up. This objective is something I have been wondering about. 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 and WTP more complicated, complicating the configuration and management. I know that the vendors are basically not in agreement about the right technical solution, and that some vendors are providing split MAC while others are providing local, so I'm afraid any attempt at an objective discussion on this will degenerate into both sides supporting their particular product offering with material from their respective marketing departments. The other problem with trying to choose is that I can think of good technical reasons in support of both alternatives. I can also think of good nontechnical reasons to choose one or the other. One way we could solve this problem is to structure the protocol such that the two choices are clearly separate and let the market decide which way to go.That way, if CAPWAP is progressed to Draft Standard, if one or the other fails to achieve widespread deployment, the alternative that is not deployed can be EOLed. There are other possible ways to cleanly separate the two, but they involve making some kind of value judgement that, I'm sure, one side or the other will object to based on the perceived impact of that judgement on their market capture potential. jak ----- 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 "5.1.1 Objective Details 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 WTPs using a single CAPWAP protocol. Integral support for these designs comprises a number of protocol aspects. i. Functionality negotiations between WLAN controller and WTPs Local MAC and split MAC designs differ in the degree of IEEE 802.11 MAC functionalities that each type of WTP realizes. The CAPWAP protocol should allow WLAN controllers to determine the functionalities of different WTPs as a first step in controlling them." "determine the functionalities of different WTPs" - we should not assume that all Local and Split WTP vendors will select the same set of atomic 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 hundreds (ok, ok, so I am exaggerating a bit) of instances per each group (Local and Split). Regards, Emek Sadot System Architect Group Avaya Communication 732-852-2367 _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Feb 28 12:52: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 MAA15669 for ; Mon, 28 Feb 2005 12:52:08 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6B94620380; Mon, 28 Feb 2005 12:52:07 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C4B68202C0; Mon, 28 Feb 2005 12: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 B4F12202C0 for ; Mon, 28 Feb 2005 12:51:42 -0500 (EST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 85A191FFF3 for ; Mon, 28 Feb 2005 12:51:40 -0500 (EST) Message-ID: <004201c51dbe$4ea6c070$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Yao Zhong Hui" , References: <20050226170002.21051.87541.Mailman@xavier> <00a201c518c5$c3b39f80$870aa70a@jys3101091805> Subject: Re: [Capwap] RE: CAPWAP Objectives rev00 - 5.1.1 Objective Details (Zhonghui Yao) MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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, 28 Feb 2005 09:52:39 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Yao, > In fact, the difference of WTPs is not only between SPIT and LOCAL, but also among Split WTPs from different vendors. So, following the objectives should be the CAPWAP functions definition. I think we can summarize the CAPWAP functions into two groups: I would think that the point of a standard protocol should be to eliminate gratuitous inter-vendor differences. The protocol might include a "vendor specific" option, such as Radius has, if there are good reasons why vendors need to extend it. > > (1) Wireless MAC/PHY-layer related management and control > This group functions may include such as BEACON parameter setting, MAC-layer management frame transfer etc. > > (2) Wireless MAC/PHY-layer independent management and control > This group functions may include firmware management, data plane management, User Authentication and Key distribution, etc. > Are you proposing that the protocol might be designed in such a way as to have a common set of operations between split and local MAC for the second set of operations, and that they would only differ on the first set? jak _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap From capwap-admin@frascone.com Mon Feb 28 23: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 XAA11525 for ; Mon, 28 Feb 2005 23:00:07 -0500 (EST) Received: from localhost (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A6CCB204E3; Mon, 28 Feb 2005 23:00:06 -0500 (EST) Received: from xavier (xavier [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D786E204DB; Mon, 28 Feb 2005 23:00: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 850FF204BC for ; Mon, 28 Feb 2005 22:59:48 -0500 (EST) Received: from huawei.com (usaga01-in.huawei.com [63.250.163.245]) by mail.frascone.com (Postfix) with ESMTP id 8DB14203A1 for ; Mon, 28 Feb 2005 22:59:46 -0500 (EST) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICN000C3MXRE2@usaga01-in.huawei.com> for capwap@frascone.com; Mon, 28 Feb 2005 19:56:16 -0800 (PST) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ICN009AEMXQYY@usaga01-in.huawei.com> for capwap@frascone.com; Mon, 28 Feb 2005 19:56:15 -0800 (PST) Received: from [172.24.1.3] (Forwarded-For: [10.78.68.155]) by szxmc02-in.huawei.com (mshttpd); Tue, 01 Mar 2005 12:00:09 +0800 From: Yao Zhonghui 4776 Subject: =?gb2312?B?u9i4tA==?=:Re: [Capwap] RE: CAPWAP Objectives rev00 - 5.1.1 Objective Details (Zhonghui Yao) To: James Kempf Cc: capwap@frascone.com Message-id: <8ccc558cc564.8cc5648ccc55@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: quoted-printable Content-disposition: inline X-Accept-Language: zh-CN Priority: 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: Tue, 01 Mar 2005 12:00:09 +0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Jak=2C Yes=2E I agree your comments=2E Zhonghui Yao ----- =D4=AD=D3=CA=BC=FE ----- =B4=D3=3A James Kempf =3Ckempf=40docomolabs-usa=2Ecom=3E =C8=D5=C6=DA=3A =D0=C7=C6=DA=B6=FE=2C =C8=FD=D4=C2 1=C8=D5=2C 2005 =C9=CF= =CE=E71=3A52 =D6=F7=CC=E2=3A Re=3A =5BCapwap=5D RE=3A CAPWAP Objectives rev00 - 5=2E1=2E= 1 Objective Details (Zhonghui Yao) =3E Yao=2C =3E = =3E =3E In fact=2C the difference of WTPs is not only between SPIT and = =3E LOCAL=2C but =3E also among Split WTPs from different vendors=2E So=2C following the = =3E objectivesshould be the CAPWAP functions definition=2E I think we = =3E can summarize the =3E CAPWAP functions into two groups=3A =3E = =3E I would think that the point of a standard protocol should be to = =3E eliminategratuitous inter-vendor differences=2E The protocol might = =3E include a =22vendor =3E specific=22 option=2C such as Radius has=2C if there are good reasons= = =3E why vendors =3E need to extend it=2E =3E = =3E =3E =3E =3E (1) Wireless MAC/PHY-layer related management and control =3E =3E This group functions may include such as BEACON parameter settin= g=2C =3E MAC-layer management frame transfer etc=2E =3E =3E =3E =3E (2) Wireless MAC/PHY-layer independent management and control =3E =3E This group functions may include firmware management=2C data plan= e =3E management=2C User Authentication and Key distribution=2C etc=2E =3E =3E =3E = =3E Are you proposing that the protocol might be designed in such a = =3E way as to =3E have a common set of operations between split and local MAC for = =3E the second =3E set of operations=2C and that they would only differ on the first set= =3F =3E = =3E jak =3E = =3E = =3E _______________________________________________ Capwap mailing list Capwap@frascone.com http://mail.frascone.com/mailman/listinfo/capwap